The Second Coming of Java | Hacker News Reader

The Second Coming of Java

wired.com

67 pointsrck83 comments

I can't figure out what the target audience of this post is.

It's without doubt not programmers, as the article tries to explain what a programming language is "...It’s a programming language, a way of writing software code..."

And also, who is going to be interested in a story about java if they aren't programmers or in the IT business?

The author seems to not even know what a JVM language is. "...Originally, the Java virtual machine — aka the JVM — only ran code built with the Java programming language, but today, it runs all sorts of other languages..."

Another example where the author is not being consistent "...language called Clojure to a new and increasingly popular invention known as Scala...Lisp, a way of quickly scripting code"

So now clojure is a language, Scala an invention and Lisp, a way of quickly scripting code.

This article is making noise without talking to anybody.

Tech leadership or programming enthusiasist are potential targets. I gather the average person is actually the target due to this statement: "If you know Java at all, you probably think of it as something from the late ’90s, a child of the original internet boom, a little piece of downloadable software that sent a cartoon mascot dancing across your Netscape web browser."

I can't figure out what the target audience of this post is.

It's part of Wired's "Enterprise Technology" blog[1] so it's for CIO/CTO and other IT consultant types who don't write any code themselves, but make "best practice"[sic] recommendations.

[1] http://www.wired.com/wiredenterprise/

"I can draw the Javas on a whiteboard but I can't actually do the Javas."

This is a common refrain for all of the articles published in this column. They also made like 10 variations or so of the same article about Hadoop, Dremel and related software without actually explaining anything of value about the platform.

I guess the audience is whoever gets to see the ads.

"...Originally, the Java virtual machine — aka the JVM — only ran code built with the Java programming language, but today, it runs all sorts of other languages..."

I'm confused what your main problem here is, besides it's almost lifted straight from Wikipedia. From Wikipedia: "Although the JVM was primarily aimed at running compiled Java programs, many other languages can now run on top of it." So, as far as I can tell from what's quoted, there's not much wrong with what was said. Please clarify.

Also, isn't Clojure a programming language? Does Wikipedia also lie here? If it's not, then what is it?

Calling the JVM platform a relic is a major mistake - the number of businesses that rely on the platform is massive.

However Java-the-language has been stagnant since Java 1.5 in September 2004. The Java API has had some changes but the language has remained mostly unchanged. The 1.8 version promises some nice improvements inspired by FP languages. Unfortunately, 1.8 has been continuously delayed with a current release date of sometime in early 2014. For JVM developers who care about their productivity, moving over to languages such as Scala, Groovy, and Clojure is the only sane choice.

I may be wrong but afaik java 8 has been delayed once (http://mreinhold.org/blog/secure-the-train)

Many of the productivity features we're talking about (e.g. lambda) were originally supposed to be in java 7, so have already been delayed multiple times.

Java fills a particular niche (code with an emphasis on readability) which is not addressed by Groovy or Clojure and arguably not addressed by Scala. I'd say Go is the biggest competition for that niche as a language, although it's not JVM, it does fix many warts with how Java handles inheritance/polymorphism without sacrificing readability and simplicity.

Groovy is slow as a 1-legged dog. (we use it to fill the shell/perl niche a lot but it is slow, effectively you're doing reflection lookups every time you call a method in Groovy). The dynamicness makes it better for scripting or web programming, though, where you don't care as much about performance.

Scala is the JVM's C++, a giant pile of overlapping features, supported by an advanced and very slow compiler that yields fast bytecode. Case classes, funny operator overloading, lots of additional syntax for collection manipulation. They're giving you more expressiveness at a cost of readability and language complexity. (This is an opinion, some may disagree).

Clojure is really awesome but most dev shops will have an easier time with imperative programming models.

Ultimately, not changing in 8 years isn't fundamentally bad, and Java isn't that bad at all as a language if you avoid things like EJB and Hibernate, and if you're not looking for a dynamic language like Ruby and dissapointed by Java not being Ruby. You might just disagree with the tradeoffs.

I'd argue Scala is much more readable than Java with some effective practices. Type inference (where appropriate) cuts down on distracting text, operator overloading is great when used judiciously, for comprehensions, etc are all great features.

Just because Java requires explicit typing all over the place does not make it easy to read, especially when I'm trying to decipher what the ResourceBuilderFactoryFactory class is doing in my enterprise grade codebase. There is cognitive load in parsing tons of text to express simple concepts, just as there is cognitive load in deciphering a bunch of random symbols doing something complex. Scala with discipline lets you choose somewhere in between; Java gives no choice.

Type inference is great, and is part of why I consider Scala to be "one step forward, 2 steps back" rather than just a total loss.

As far as the rest, we'll just have to disagree, I stated up front that it was an opinion :)

Haha, well what you said is true, but your spin on it I disagree with. How about "one step forward, a couple steps to the side"?

For startups with small, disciplined teams, Scala is manageable, sure. But once things go "enterprise" and much of your ongoing development gets outsourced, and it will, all bets are off. Maintainability is THE great equalizer.

It's my personal goal at the current company I'm at to see Scala grow to be respected as an "enterprise" language. The startup where I learned Scala had a small disciplined team with lots of mentorship that meant almost everyone developed some very good Scala practices.

If code is becoming unmaintainable because of outsourced development, does that not have more to do with how we communicate to these external developers? Bad code is bad code in any language.

> But once things go "enterprise" and much of your ongoing development gets outsourced, and it will, all bets are off.

That has nothing to do with language; Java for which development is outsourced and maintenance goes in house is pretty much a nightmare, too.

But that's pretty much a "myopic development practices -- including outsourcing development of code you are going to need to end up supporting in house -- will blow up in your face problem", and not an issue relating to any particular language or platform.

Chances are, if you have the authority to make enterprise-level language/platform policies, you also have the authority to make enterprise-level decisions on whether and when to outsource development of software, so it makes sense to just do the latter right than to make an otherwise second-rate choice on the former to make up for doing the latter poorly.

> Scala is the JVM's C++

Thats what I've been thinking (and posting) since some time now, nice to see I'm not the only one. I know some Startups regretted choosing Scala.

I would imagine without strong leadership you could end up with code looking completely different between programmers.

which ones ? i beg the differ.

For me its a benefit, why would you want your language/core api changing all the time? Thats how you end up with certain unnamed languages that have fallen out of favor. Java the language tries very hard to not be redundant in its feature set, so the path to usage is clear.

I think Java suffers from too many search results (yes thats a thing). I suppose if you want to learn Java today you simply google it, and find tons of people trying to solve the N+1 hibernate problem on stackoverflow, or some other common annoying enterprisey issue, and so you start reading up on JCPs and EE apis. If that is your introduction, I can understand why people end up going "what is this shit?". The reality of course is that there are many subcultures within the Java community and that many of them are anti cruft api as well which is how innovation comes to the Java world.

Yeah, a good rule of thumb is that if something was specified by a JSR, it's probably shit to work with because of all the competing corporate agendas that went into it.

It works sometimes and not others.

For example, if someone put as much effort in .Net's original collections API as they did with Java JCF, many a facepalm would have been avoided.

To be honest the whole JSR process is usually hindered by shoddy implementations rather than fundamental problems.

I'm curious to know if Groovy 2.x (with strict/static compiler pragmas, er, annotations) is slow relative to regular Java lang code. I know Grails doesn't use the strict mode stuff, but for hand coded "hot spots", how does Java vs Groovy 2 compare?

> Grails doesn't use the strict mode stuff

No one uses the strict mode stuff except those unwittingly beta testing it for Grails. It was written by one lone programmer and is still buggy.

Hmm. Interesting. I recently incorporated Groovy into an existing legacy (web) app. As the app is still under Java 1.5, I could not get the static/strict stuff to work - it needs 1.6 or better support.

So, there's consensus that this feature is not ready for prime time? (I don't want an answer from people who hate Groovy in general)

> So, there's consensus that this feature is not ready for prime time?

Best wait till Grails trusts the static enough to use it before you do.

> I don't want an answer from people who hate Groovy in general

I love the Groovy Language, but the current PM made some bad decisions after taking over, e.g. removing Poirier's Heredocs, disabling Scala-like catchless try statements, laundering Tkachman's Groovy++ static-typing plugin, stonewalling on Wilson's MOP upgrade, scuttling any attempt to spec the language, the horrible paren-less DSL syntax for multi-arg function calls, removing Closure Lists just before an RC release without any public discussion, how Strachan the founder was knifed over dynamically-scoped closure syntax at Devcon 2, how Java 8 lambda retrofit hasn't even been begun on, instead the PM is wasting time on non-Java compatible traits to Groovy, etc.

I still love the essence of the Groovy Language, tho, that's why I'm rebuilding it atop Clojure.

Groovy's niche is supposed to be the same as Ruby or Python - if you want high performance, it's not the way to go. I've done a lot of Groovy for simple web applications and it works very well.

You don't have to use funny operator overloads if you use scala! Making your code readable in that language is definitely up to the developer.

Actually, Scala core is pretty small. What you think as operators are methods. What you call case classes is pattern matching , one of the most powerfull feature of Scala along with Actors.

> lots of additional syntax for collection manipulation

Actually using collections in Scala is far more easier than in Java

And i'm not even talking about XML parsing... where you would write 30 lines in java you'll write one liners in Scala. Guess which one is easier to read...

Scala promotes immutability that make code sane.

Scala promotes recursion over loops that makes the code elegant.

Scala promotes experimentation through its REPL.

Scala saves you writing 75% of the java boilerplate, thus promotes maintainable applications.

Scala looking much like Java is a deception but also an necessity for compatibility which Java libs. but the syntax has a total different meaning . That's the genius of Scala. Scala is the guy looking outside the box when Java is trapped in Cargo Culting.

Scala is the future of the JVM.

> Scala looking much like Java is a deception but also an necessity for compatibility which Java libs.

The fact that Scala can look a lot like Java is more for compatibility with Java devs; the code could look a lot different (and idiomatic Scala does) and still be compatible with Scala libs, but supporting code that is familiar to Java devs eases the learning process and encourages adoption.

This post comes across like you're incredibly ideologically invested in Scala. I'd suggest that 'the future of computing' in any dimension will take a lot more from practicality and a lot less from theory or ideology.

Specifically, the point about encouraging recursion for more 'elegance' kinda bugs me there. Recursion is more of a natural fit than loops when walking a tree or graph, and is less so when iterating a list, set or map. It's about practicality.

If you're very interested in aesthetics, you'll never like java or even not-hate it. And that's ok.

Did you test statically typed groovy? Does it have better performance?

As for clojure, how does its performance compare to groovy?

Really interested to know more!

Clojure can be exactly as fast as Java within a function when type hints are used to avoid reflection. Calling Clojure functions has a little overhead relative to calling Java methods.

That said, an idiomatic system in Clojure will likely have a very different design than it would in Groovy or Java. Using Clojure's built-in immutable data structures, it's cheap in terms of CPU and memory to make a large number of modified copies or to concurrently access data compared to the standard collections in Java and Groovy. Single-threaded reading and writing are, however somewhat more expensive.

My prediction is that it's easier to get good performance out of a system with a lot of concurrency using Clojure than it is with Groovy or Java, though with careful design, it's possible to get better performance with Java.

EJB (and particularly entity beans) is the worst thing that ever happened to Java and, arguably, enterprise development.

It's still unbelievable to me that so many shops drank that Kool-Aid.

Java fills a particular niche (code with an emphasis on readability)

I'm a bit skeptical of this claim. While Java does remove many of the opportunities other languages provide for making a small piece of code do something unexpected, I've found that Java's verbosity makes it hard to see the big picture.

Of course, good programmers manage in spite of any limitations of the language, and bad programmers manage to write incomprehensible code no matter how much a given tool tries to guide them in the right direction. I suspect it will always be this way, and that's not a bad thing.

Java programmers seem to love the swap too. All the ones I've seen in shops that have swapped love the transition

That's a little generous. Clojure is great and I enjoy working with and Scala is fun too, but Java still has the best tooling support. Scala IDE has weird little bugs here and there whereas I haven't encountered a JDT bug in years.

I use Eclipse for all of them Counterclockwise, ScalaIDE and JDT. Counterclockwise is actually really nice. Selecting forms is super simple and makes the parenthesis "issue" not a thing.

It's a shame there isn't an "employable" choice of language platforms somewhere between a GC-ed language and C.

The JVM has an exquisitely tuned GC, but any GC still comes with a cost. But do I have to use a language with no safety features at all if I opt for other non-GC languages?

(I'm of course thinking of something like FreePascal, but there must be a number of good middle-ground alternatives that are being ignored in the work-place, which would easily write less hardware-hogging code)

I would not have thought the above comment was offensive. Perhaps somebody doesn't like having his/her choice of language questioned??? (whether it was Java, or C, dunno)

My hammer rocks!!!

> moving over to languages such as Scala, Groovy, and Clojure is the only sane choice.

Anyone who mentions these three languages in the same breath is regurgitating the marketing talk for one of them. The article doesn't make that mistake, so could actually be genuine research rather than some PR drivel from some corporate Product Manager.

Java has steadily grown over the years as the premier choice in the Enterprise. This is the reason that Java developers are relatively many (though I don't believe they are falling from the sky as the article suggests).

This article is a little strange in general. The idea that Java was ever dead seems to be from the perspective of those who thought it was only for applets or devices. But the author acknowledges his awareness that this is not all Java ever was. So, to make the case that it died, he holds out a few examples of companies that tried something else, but couldn't scale until they went to the JVM. He simultaneously ignores the entire Enterprise Java world.

Odd.

Yea, it's like the author switches perspectives to push his narrative. For normal end-users Java has all but disappeared from their ecosystem. But for enterprise programmers it never went anywhere.

Exactly. It would have been a more interesting (or at least accurate) article if he'd actually focused on Java's enterprise success, then talked about how these once "edgy" start-ups somewhat ironically wound up moving from "trendier" languages/stacks, back to the Enterprise stalwart, Java.

From the point-of-view of a web developer, JSP is virtually invisible. For this reason, I guess the majority of online tech magazine readers, who would presumably be mostly ninjas, pirates and rockstars, would think of Java as dead.

I mean, it's a bit outdated as a language, definitely showing some signs of strain, but it's still not dead - for better or worse. I've yet to come across a more human-readable language, barring COBOL.

For readability nothing beats BASIC. I sometimes wish that BASIC had taken off rather than being allocated to niche environments like VBA etc. It just wasn't powerful enough and in order to make it more powerful it was kind of bastardized into something almost unrecognisable form its origins.

> For readability nothing beats BASIC.

For readability, structured/OO/etc. languages that don't use particular terse basic constructs (e.g., idiomatic Pascal, Python, or Ruby, but generally not C/C++) beat BASIC hands down; structured and OO descendants of BASIC are pretty much in the same readability level as other mainstream non-terse structured and OO langauges.

>From the point-of-view of a web developer, JSP is virtually invisible.

By "invisible", do you mean that webapps that use JSP typically use URL mapping so that you never see the .jsp extension? If not, then I'm not sure I get your meaning.

>I've yet to come across a more human-readable language...

Yeah, I think its readability leads to a verbosity that is, ironically, the source of some complaints about Java. But, Java kind of embraces that verbosity to some extent. I've even seen style "standards" that discourage the use of language "shortcuts" because they are believed to decrease readability.

> By "invisible", do you mean that webapps that use JSP typically use URL mapping so that you never see the .jsp extension? If not, then I'm not sure I get your meaning.

Oh, I just meant that JSP is never, ever mentioned in any mainstream web development magazine - it's absent from discussion, not practice.

Back-end programming seems to be exclusively PHP/ROR if I go from what I read on web dev blogs, forums and news sources. I may simply be reading the wrong sources, of course.

I love Java but I hate Oracle more than any other tech company. I don't refuse to use the language but I don't like to either if I can help it. I really hope with OpenJDK we can just forget about Oracle in the long term and have a solid language/platform that is free from a corporate parent.

Java applets are dead, and should be. Great idea poorly executed.

Java on the server never died or even coughed. It's huge. It's a very rich ecosystem and performs very well at scale.

Java for apps is IMHO underrated. The biggest foot-shooting decision Sun made was to bundle shitware like the ask.com toolbar with the JRE, and never to solve the JRE deploy/update problem that requires that every Java app bundle its own JRE. Solve that and java apps on desktop computers will make a comeback.

> Java applets are dead, and should be. Great idea poorly executed.

I think Microsoft killed the applets when it stopped upgrading the java plugin in IE. Applets were challenging MS dominance on the desktop. They kept it that way until java script came along.

Java never really went away. This article to me is really more of an attack on the recently/currently trendy technologies like Ruby on Rails than anything else.

As long as companies and organizations will have legacy code, not a single language will ever be considered dead.

so very true

And overlooks that a "scripty" language helped get a minimum prototype done much more easily than COBOL-esque Java coding.

Of course, if your site becomes popular, performance matters later.

The article is terrible when read from the perspective of a developer. But it does touch on something - often here on HN, start up culture and wider tech-centric sites if a technology is mainstream, not release 0.001 its not considered worthy of attention or praise and gets an unhealthy amount of sour grapes. Java/JVM is ubiquitous in our field and has been quietly getting the job done for over 15 years in that sweet spot of fast, server-centric applications. I'm looking forward to v1.8 where it will pick up the features needed to keep it an essential tool.

I think that saying it's the second coming is misleading. It was no longer considered sexy and cutting edge by the startup community, but as the web spread to every corner of every industry it was by far the language and platform of choice for thousands of IT departments. The result is an unmatched galaxy of scalable products that can be dropped in to any web application.

Some of this article reads as if it were a "Special Advertisement Section" paid by Oracle to fend off the negative press Java has been getting from the recent spate of security exploits.

Its good that it mentions the JVM-based languages though. I know many "Java" programmers who hate Java proper but love languages like Groovy, Scala, etc...

"Java is really the only choice when it comes to the requirements for a company like ours — extreme performance requirements and extreme scalability requirements. There is no viable alternative"

What about C#?

Is that a joke? [I mean both the quote and the retord]

C#, clearly, did not meet their expectation.

Some people like to earn money, but avoid paying for developer tools.

It has nothing to do with dev tools costing money. It has everything to do with Windows costing money.

It is the same thing.

C# is not a plateform. When people talk about Java it is the JVM , not the language. .NET is no alternative to java, i cant install .NET on a *nix server ( and no, Mono is not an alternative either).

> The best way was a brand new architecture based on Java, a programing tool that grown more powerful than may expected.

Kudos on the proof reading.

Well, you can't expect the editor to ask june, july and august, too.

With the 1.0 beta release of Ceylon, it is pretty clear the JVM is still a pretty useful basis for new languages... http://ceylon-lang.org/blog/2013/09/22/ceylon-1/

Neal Ford said: "In a keynote address that I once co-presented with Martin Fowler, he made a perceptive observation: The legacy of Java will be the platform, not the language."

The performance metrics for some JVM-based technologies are really impressive but I continue to see performance problems with Java (the language) based software. In my field, very high speed network data processing work is done with C/C++ out of necessity.

You are correct. Java's niche is servers that need to accept a lot of concurrent connections and middleware that can shove data around via a set of standard protocols. Outside of those enterprise-centric areas, it's not a great fit for much else (fast data processing, embedded, games, etc.) I say this as someone who has worked with server-side Java since 1999.

Never left, actually

The idea that Java is a "Clinton-era relic" is pretty ahistorical when you consider that Google and Amazon have been using Java on the server side since their early days - it never went away. The tech press just didn't pay attention to it.

This article makes it sound like an either-or, but JRuby is a mature alternative that allows you to pair Ruby's excellent web tools ecosystem (Rails foremost within it) with the ability to shunt off expensive tasks to Java or another JVM language.

isn't this just a single example of 'right tools for the job' and the common sense that ruby has abyssmal performance owing to /its/ architecture compared to java and so simply can not scale as well as a like for like implementaton in java (which can be said to have abyssmal performance compared to /good/ native bytes, C or C++ [although that gap is narrowing significantly in many areas - especially when sloppy code is involved]).

Even Groupon, arguably one of the largest Rails-based sites still out there, is moving away from Rails. (Mostly to Node.js although again, with some Java).

(And yes, obviously Ruby != Rails.)

Yeah,like "Enterprise" Node.js projects are managable with a team of hundred of developpers... they are not.

Node sucks at database interaction, sucks at performance(computation) , the only thing that nodejs does well is concurrency ( handling concurrent connections ) but it doesnt make the js code running inside nodejs fast(computation).

In fact it is not. Your server wont die fast because Nodejs can handle a lot of connections , but the end users will wait a very very long time for a response. that's the truth about NodeJS.

The second coming of Java the platform (the JVM), at any rate.

I'm just a novice programmer, but it is my understanding that Clojure is a Lisp dialect, it doesn't just feel like Lisp. Am I correct?

It's got some differences, notably a vector type with square [] brackets that is differentiated from homoiconic function calls in normal (), and also some hacky stuff with (recur) that they had to do to deal with the JVM's lack of tail call optimization.

Isn't [...] just syntactic sugar for (vector ...)?

The point about tail call optimization is interesting though. I wonder what it would take to implement that on a JVM.

I'm not enough of an expert on Clojure or Lisp to answer (my lisp knowledge is extrapolated from scheme in college).

I believe that Rich Hickey said that having special notation for vectors (and for maps, I remember now) was about, basically, yes, that syntactic sugar. He was specifically comparing to lists in () which are somewhat indistinguishable from function calls in (), hence an example of overloaded parentheses.

Java is slow. It's going nowhere fast. LLVM on the other hand...

"In the summer of 2011, Bob Lee - the [CTO] at Square and a former engineer at Google - announced... that the web was 'on the cusp of a Java renaissance.'"

I'll bet he wouldn't make that same announcement today.

Reply on news.ycombinator.com