Hacker News new | comments | show | ask | jobs | submit login
The Rise and Fall and Rise of Java [video] (marakana.com)
93 points by javinpaul 1368 days ago | hide | past | web | 86 comments | favorite



High level summary / notes :

* The talk mostly deals with Java the language, not so much the JVM

* It's generally a non-technical presentation, looking at the language & adoption trends from the POV of an analyst

* It appears primed to address and/or alleviate concerns about the current and future state of Java's adoption in the workplace and open source community

Rise, Fall, Rise :

* Much of the talk is a bit of a historical overview of the progression and adoption of Java. Several visualizations are shown, typically contrasting Java's adoption and job market against that of other popular languages (C / C++ or Python, Ruby, JavaScript - depending on the time period involved).

* Take home from the above : Java is not in decline (in adoption and job rankings) relative to other major languages.

* A Stack Overflow survey result is presented, showing a weak but statistically significant correlation between Java use and age (slightly older developers being a bit more likely to be familiar with Java)

* Java is still being used in major open source initiatives (Hadoop, Lucene, Cassandra, as well as a number of projects released by Netflix). This is presented as a particularly reassuring sign of Java's role in the development ecosystem. IMO I agree.

Additional points / Java's shortcomings :

* Java kind of sucks at reducing friction of deployment. Illustrated by comparing PostgreSQL's friction of installation to MySQL. The talk refers specifically to things like ease of installation & configuration, but (IMO) the lack of a single, unified, simple package management system is just as lacking in this regard

I'm sure there was more, but I mostly watched the talk in the background. I found it interesting, although it didn't mention anything that I would consider to be earth shattering.


I've gotta take beef with the deployment comment, we use Java at my job and the deployment is quite specifically awesome. There is a single package management system, maven repositories, and multiple build options using that management system.

But the reason deployment is awesome is because of the nature of shipping an assembled pile of bytecode. You can build an assembly that statically links in all the code you depend on, and bang: You have one jar (or war) file, can run java -cp myjar.jar MyClassName and all of your dependencies have been packed into the jar for you. It's so easy. No management of which dependencies have been installed where.


I think it helps to look at the scope of the analogies being presented. For instance, the friction of installing & configuring Postgres is compared unfavorably to MySQL. Objectively speaking, those are pretty minor differences (i.e. installing Postgres is easy). However, the point that was being made was that even minor increases in "friction" can negatively impact adoption.

No-one is saying Maven / Gradle / Ant are terrible package management systems. However, when compared against tools used in other popular languages (ruby gems, pip, NPM), it's fair to argue that other language's package management systems are more fluid - in that neither of them require prior configuration and work quite well outside of an IDE.


Maybe these other systems are more fluid, but their are also a lot weaker in what their platform gives them. What I mean by this is that the Java world never needed the extra rvm, virtualenv, etc.

The complexity of dependency management doesn't come from declaring dependencies, but from managing conflicts over time and being able to create isolated environment.

Even if many call it the "jar nightmare", I don't know other systems that offer better isolation.


I think you've misunderstood the point I was making, which makes sense in context of the video in the OP. I'm not arguing NPM > Maven. I'm arguing NPM is conceptually simpler and easier for a newcomer to use than Maven.

Namely, the speaker made reference to "weaker" DB technologies being used due simply to a frictionless barrier to entry. Mongo was cited as one example. The use of MySQL over Postgres was another. This is basically taken verbatim from the presentation in the video.

This isn't about which systems are "better" or "worse", but which are simpler to get up and running with. Mongo is super duper simple to install and configure. So is NPM. Managing complexity is a real and valid concern, but also not what we're talking about here.


What I wanted to suggest is that: at the tool level npm, gem, pip are simpler to get started. But I don't think that's the case at the env level where you'll need more tools.

So while I've used some wrong words in my comment, I was still (trying at least) referring to simplicity vs complexity.

PS: I've never been very fond of other complexities introduced by the maven approach, but that's a different (and probably longer) story.


Yeah, that's what I'm disagreeing with.

Maven doesn't require an IDE and uses a convention over configuration based approach where it will run against the public repo with zero config.

Moreover, it's significantly 'more fluid' due to the ability to ship assembled fat binaries that have all of their dependencies packaged with them. No need to worry about which version of what is installed on this machine.


I think you glossed over the 'configuration' that adds friction to Maven adoption. Namely, the pom.xml file. You could argue that its complexity is typically overstated, but the fact remains that it exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

> No need to worry about which version of what is installed on this machine.

That's not a concern when using NPM (out of the box), and when using virtualenv it's not a concern when using pip (which most Python devs do).


> the fact remains that it [Maven] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

Are you saying that when developing in Node, you don't have to interact with npm or other build & deployment utilities? End-users of packaged Java applications don't have to interact with Maven any more than end users of packaged C applications have to interact with Make.


I was probably not clear. 'It' refers quite specifically to pom.xml, not Maven as a whole.

Thus :

> the fact remains that it [pom.xml] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

Again, I would like to highlight that this entire discussion should be viewed through the lens of friction vs. frictionless tools, and what that means for community adoption.


A big part of the ease of use of package managers comes from implicit trust in the maintainers of the repositories. Convention over configuration dictates you as a node dev trust the NPM repos. Ditto for ruby gems.

Like most things java related maven is very extensible from an env perspective. People complain about java programs/tools being over engineered but in this case it's a good thing.

One of the great things about maven is that you can trivially point it to a repo you control that is shared across a team or even an entire corporation. This allows whitelisting of packages, confirmed trusted versions, and consistency across different applications (my app and you app both use library X and we know its the same jar).

How many of you actually verify the origin of the modules and libraries you use as dependencies?


I think you got it backwards. Maven doesn't support any form of authentication or verification for packages. So you better trust the network you're on, the core network, and the remote repository.

Maven central and other repositories contain a lot of software, under many different licenses. So unlike, say, apt-get or rpm, you can't always be sure that what you're getting is free/open source software. Be careful with the licenses!


Going back a step, Java itself is just download, unzip. Oracle actually made it even easier than Sun, by doing the "agree" on the website. But they do lose by not having it in ubuntu/debian.


It's not so easy in the corporate world because you need Administrator access to install Java.


If you specify the right options in the manifest (or configure the maven assembly plugin appropriately) you can reduce it to java -jar myjar.jar.

But these megajars have other issues when you need to run in slightly more advanced scenarios, e.g. hosted Akka or Play. It's not hard to end up with multiple versions of the same library on the classpath, and the wrong ones getting chosen.


I use SBT-Assembly with Akka to generate megajars and I haven't had any issues with multiple dependent libraries getting packaged with conflicting versions. SBT-Assembly has a pretty straightforward system for handling conflicts, allowing you to define merge strategies for different files or patterns.


The problem with something like Akka Microkernel is that you get multiple megajars for different actors, living in the same JVM, with conflicts in the libraries in the separate megajars.


I listened to it as well and your summary is a good one. If I were a Java developer in the audience I'd feel reassured, but not too excited.


> The talk mostly deals with Java the language, not so much the JVM

Have yet to watch the video, but my biggest problem with Java was THE language and swing.


I like Java. I am able to be quite productive with it along with Spring and Guava. Hibernate, though somewhat finicky, makes dealing with databases almost trivial. I honestly don't see any reason to learn Scala other that syntactical simplicity. That said, I love Clojure -- it forces me to think differently and I like that.

Some people hate the java ecosystem --Maven, ant, gradle etc. etc. I find Maven to be incredibly useful , though not simple. Cruise Control with Maven and Junits simplify code management greatly.

Then there is Servlet 3.0 specification with standardized async support. My benchmarks on spring async controllers on Tomcat 7.041 show mindboggling improvements for some my particular use cases that involve several Webservice Apis .

I thought I would put it out here. I have witnessed no fall of Java. Only better hype from other language proponents.


> I like Java. I am able to be quite productive with it along with Spring and Guava. Hibernate, though somewhat finicky, makes dealing with databases almost trivial.

Spring and Hibernate made me abandon Java. I still recall my reaction when I started to learn and program with it: "If this is the way I'm supposed to solve issues and ship software, the tool (Java) is obviously not doing its job."


He didn't delve much into the proliferation of JVM-based languages, which is significant, even if Java (the language) doesn't have the same 'excitement'.

What I expected to hear, but didn't in so many words:

The trend of people migrating to higher-level languages will continue. Of course, if performance is important, you'll move to C or C++ at the other pole. Read PG's "Beating the Averages".

Considering the growth of multi-core programming, there will be movement towards the high-level end of the spectrum (Lisp). The languages people will eventually end up at will be something JVM-based (so Clojure, or at least Scala), if Twitter's move from Ruby to JRuby to Scala is any indication of the failings of Python/Ruby to handle multi-threading.

Frameworks like Hadoop, and lightweight servers like Jetty, allow people to program for HPC and web servers in JVM-land while being OS-agnostic. Once the migration to high-level JVM languages takes shape, Java will be the new C -- a "high-level assembly" language.


He's saying exactly the opposite - he's saying that Java the language (not JVM - he never actually mentions the JVM at all) is on the rise. Java is very much not turning into a "high-level assembly" language and is not dead or dying.

I'm not sure how a language with garbage collection, lambdas now in Java8 and the kind of DI you get with Guice can possibly be considered anything but a high level language.


You really need to learn a functional language.


So a functional language is somehow 'higher level'? You need to go look up the definition for 'high level language'.

Also, feel free to check out Nitro, a low level functional programming language.

http://homepages.inf.ed.ac.uk/stg/workshops/TFP/papers/Clark...


Both of you make valid points. It's all relative.


You have to agree that there is some truth to O'Grady's arguments. There has been a lot of hate about Java in the recent times, but its not just inertia that is keeping Java in the market. There is just no competitor to that language and its ecosystem. The youtube description refers to these new languages "newer, more hyped alternatives". As much as I would love functional constructs, syntactic sugar in Java, such features are not solving the real problems one expects from a programming language in the long run.


Exactly. Five years ago Ruby was the savior - now everyone and their mother is out to show how node is the new hotness.

If you've used js on a serious project you know this is just another dead end - which is why the big bucks go to jvm or clr jobs.


I've used Node and JavaScript on a lot of serious projects. Its working great. I prefer CoffeeScript though.

I have worked on a large Scala/Java project that was converted to JavaScript/CoffeeScript and the complexity, availability of modules, and especially resource usage is hugely in Node's favor.


Absolutely. It's not a very sexy language, and I can't stomach a lot of JEE, but the language and the jvm are absolute workhorses. Especially when you're dealing with high performance networking code.


Slightly off topic, but everytime I use Java I start to get this dull, drained feeling and my brain begins to slow down. And no matter how far and wide I look, applications written in Java frequently end up being slow or need many servers to perform. This is amazing to me. A verbose, mind-numbing, slow language touted as clear, compact, and fast.

I don't know how it happens, but somehow, even though it's compiled into a faster-executed runtime, many Java applications end up slow anyway.

"Powerful" language.


I'm not sure if this is complete ignorance or trolling.


It may very well be neither of those.

For a long time, software written in Java was often painfully slow. Swing apps were particularly bad. This did leave a very negative impression on all sorts of people, from developers to managers to executives to the end users who had to use these applications written in Java.

Thanks to hardware, JVM and Java class library advances, it isn't as much of a problem as it once was. But there are still many people out there, especially in the corporate and small business world, who are forced to use Java apps on desktops that are a decade old, if not older in some cases. These systems often weren't very powerful to begin with, and due to budgetary constraints they may not be able to upgrade them. It's not a pleasant situation to be in.

So while Java may appear fast enough on a powerful server, or a modern development workstation, this isn't an experience that everyone using Java applications gets to share in. When people suggest that Java is "slow", I don't think it's appropriate to discount what they're saying. It very well could be an accurate description of their situation and experience.


Knock, knock.

who's there?

(long wait)

Java.


it is always possible to explain why some particular program is running slow and in case of programs running inside JVM, JVM itself is almost never the (only) reason.


Why not just use Scala? I'm not a Java progammer and have no reason to become one, but I've been looking at Scala recently and it looks very interesting. I am a C# progammer and F# is becoming more and more compelling.


http://www.oracle.com/technetwork/articles/java/horstmann-19...

Horstmann wrote "Scala for the Impatient" (great book) and presents the issues around the language and tooling pretty fairly


The author of Scala also makes a good case. He briefly compares Scala and Clojure, then talks about the benefits of functional programming in regards to multicore processing.

http://www.youtube.com/watch?v=hiurd7KaSEI


> Why not just use Scala?

That's what we decided!

And now that's what we do.


Because Scala is not Java. Scala is complex. Java will get better with future releases but Scala is certainly not the replacement for Java.


Actually it is be a drop-in replacement for Java and I would argue with case classes, lack of ceremony, no primitive types, etc that it is a simpler language than Java.


That's my experience, too.

Of course there are things which are not quite simple in both languages, but in Scala those things are features which actually enable me to solve issues, not some language design failures from 1995 with which we have to live now for the rest of Java's life.


Because the tooling support, for the most part, is lagging.


I don't know when he asked the Postgres devs but since I've been using Postgres (2007ish I guess?) PG has been part of Debian and could be installed via the package manager in a trivial way and immediately ready to use.


Exactly. Installing postgres on any Debian system is a one line "apt-get install".

The only part that might be considered complicated is if you want to open up the server to non-local network traffic as you have to edit both the pg_hba.conf and change the listen address in postgresql.conf.

It's like that so that it is secure by default. Anyone who thinks that's too complicated doesn't understand what that means or why it's important.


It's clearly a story that got garbled somewhere in the telling, but it's hard to guess at what the original problem could have been. I'm pretty sure Postgres has been included in all Debian releases from this millennium.


Can someone summarize the video? I am curious to learn more but I don't have 45 minutes to spend on this... Thanks!


If you configure youtube to use the HTML5 player, there's an option to watch videos at 1.5 or 2X speed..

key points I remember:

* Java isn't dead, or dying; it's still among the most popular languages and growing, based on analysis of data from github, stackoverflow, and mailing lists

* It doesn't command the same relative amount of mind / marketshare as it did in its heyday, but that doesn't really matter; the market is bigger, and it's still growing

* there is a significant correlation between programmer age and use of Java

* ease of initial installation is an underappreciated factor determining which technologies get adopted and become popular


Is complete transcription available somewhere?


You should take that time, it is interesting and deserves its upvotes. Summary: Java is not dead.

He is saying that he can't build the case that Java is dead because the data says java stays popular, even though it has peaked in popularity. Data including usage on github, stack overflow, mailing list traffic and job demands.

What I found to be interesting is his part "easy wins" and how that was and is a challenge for the Java community, including a nice example about postgres on debian systems (which was not easy to install as it was not in the repositories).


The most concerning sign that Java is dead are the frequent articles purporting to show that Java is not dead.


I agree, though Java is far from going into decline (I think the salary average may be a large contributing factor), these kind of posts always feel like an indicator of things to come.


Speaker is an analyst and uses several numbers (Tiobe, mailing lists, Stack Overflow, GitHub) and examples (Netflix) to show:

a) that Java is over its peak because it has to tolerate much more languages (JavaScript, Ruby) then in 2006

b) that Java is not in decline, but at least sustaining its popularity and if you include Android you could say the 'Java semantics' is growing.

Speaker continues with some examples of frictionless technology stacks/products, and argues that Java is not that. To sustain growth it needs less complexity, better package managements, compatible licensing, low cost Java hosting.

Finally, some languages got popular by the web frameworks (e.g. Node.js, Django, Rails). But Java web frameworks are too fragmented (due to its long history as a popular language and platform). Java should take its cues from those.


Man is that last point true. Java sorely needs a neat, clean, and simple web framework. There is absolutley nothing inherent to the language that dictates that it cannot support such.


Is there really a place for a simplified Java web framework, when there's plenty of options that run atop the JVM with full access to JVM libs? (Grails, ColdFusion + several MVC frameworks, etc)


Yes.

EDIT: BTW, I think your question actually answers itself. That is, the reason there is such a proliferation of MVC frameworks is that they largely have been found lacking, so someone sets out to create another (presumably simpler) one. Simplification is almost always the motivation.

Likewise with Grails and others that run atop the JVM (which frequently even encourage adoption of completely different languages).

All of these are testament to the dearth of a clean, simple, elegant Java web framework.


It's not rising as much as become a drone assimilated by the Oracle collective -- sorry, I won't use a language who's parent company packages the runtime with crapware toolbars.

Partially joking of course -- however my experience with Oracle has not been pleasant (with the exception of VirtualBox).


To the author's point about friction: one of the things that I think has hurt Java is that some of its flagship tooling and frameworks have been overly bloated and complex. It's almost as if the more complex the technology, the more popular it became.

Eclipse must be the world's clunkiest IDE. EJBs were pure evil from the first day. And, the most popular web frameworks have been anything but simple (Struts, then Spring, etc.).

Contrary to what some may say about the language itself, I don't see anything in it that dictates tooling/dev stacks need to be so complex. It seems that it's simply the chosen architecture and/or implementation that's most to blame.


After coding in spring, and android (after having coded in other languages before), i pretty much agree that java is a quite good language. But the ecosystem is daunting.

Every single component (think ORM, build management, web stack, web server/container, serialization libs, and even IDEs) have a least 3 different technologies, which have existed for 4 to 5 years at the minimum and are up to version 10.

The Java world needs to officially DROP things. Drop librairies, deprecate frameworks, stop maintaining things. That's completely the opposite of what the enterprise world needs, but i really feel that would be really beneficial to the global perception for that language.


I think Java veered wildly off track with EJB. It's legacy lives on (unfortunately), but at, least it's not the de facto standard for enterprise dev that it once was.

So, in some senses, at least the rabid drive toward implementing the full spec has been deprecated, if not the technology itself.


IMHO: The greatest strength of Java is back-compatibility; the greatest weakness of Java is back-compatibility. Thus, it will remain viable and frustrating.

It's biggest problem (touched on in the talk) is that innovators are innovating elsewhere (e.g. sinatra). One day, this will cause the long fall of Java.

One would think Java's performance would be less important as CPUs get more powerful, but so far in practice we're seeing smaller devices and GPGPUs. It's possible Java will keep hitting a sweet-spot of usability/performance for generations to come, as C has.


re: sinatra, please check JAX-RS :)


Thanks. Yes, you can do it in Java (I did my own actually, with annotations), but...

1. copying is not innovating (sinatra was 2007)

2. it's hard to get into: http://www.sinatrarb.com/ has code above the fold; after hunting, the best code example I could find for JAX-RS was this http://www.mkyong.com/webservices/jax-rs/jersey-hello-world-...


I wonder - if Java was born today (instead of the late 90's), what would it look like, and how popular would it be? I feel like Java owes its current following to its entrenched position in a broad array of corporate and government IT departments. Also, in a sea of newer interpreted languages, it's the compiled one (and isn't C/C++). That, by itself, will win it a fair number of adherents.


In a world where Python and Ruby have a huge chunk of mindshare, I'm thinking a typed language would probably look more like Go.


Look at c# and I think you'll have your answer.


I think it's telling when two of the larger Java IDE developers have independently created their own languages to fix problems with Java (kotlin and extend).

My own sense of things since Oracle took over is that Java the language is on the way out, but Java the platform is still strong, and I expect lots of people will be gradually moving across to Scala / Clojure / something else.


I thought it was a good presentation, the chart on frameworks around time 40:00 shows what I've been thinking, seeing. If I started a site today and I had full say, I wouldn't use Spring due to its complexity (although VMware people do make a fine product - for Enterprise stuff it makes sense); still it would probably be either Grails or Play. The problem I have with Play is that even their tutorial seems to me to try to brainwash you into getting into Scala, the templating system is based on Scala. That's where they lose me. Grails I've used to build a small test site and it was great. There, I made up my mind, I would use Grails.


Views can all be straight html if you want them to be, and there are plenty of plugins for other types of templating. The Scala templates just attempt to leverage the language since you're using Scala with Play anyway (unless you're doing it with Java). The docs could use some love though.


FWIW, Even if you're using Play! from Java, the Scala compiler etc. are still being pulled in, even if it's just for compiling the routes file.


When I last looked at Play, it seemed the tooling wasn't there and not much IDE support. They tout that a simple text editor is plenty, but who wants to go without features like code completion? As I recall, the dynamic code generation made this unworkable in current IDEs.


It's funny. To Java devs, code completion is fundamental (me included, to a certain degree). The idea of having to know all of the methods available on an instance and fully type everything out seems draconian. And yet, for the JavaScript and Ruby devs of the world hacking away in TextMate, auto-completion just isn't there (correct me if I'm wrong). But, they still manage to be productive. :)


Yeah, that's true. It seems a must when you are accustomed to having it. But code completion is just one example. There's refactoring, debugging, and other support that a text editor can't give you which has real impact on your productivity. Even organizing your various config files and providing a UI for modifying them is a convenience.

I remember some years ago doing a contract for a large company. I insisted that I was cool with just a text editor. But the client's dev lead insisted that I get with the IDE program because they were paying me hourly and wanted max productivity.

In the end, after making the switch, I had to agree.


I use Intellij IDEA on Scala / Play project and mostly happy with code completion for Scala code, refactorings, navigation, routes, view, jump to the views from controllers. It's not always perfect, but perfect enough for everyday use.


Yeah, I'm partial to NetBeans, but I tried IntelliJ, just for Play. Spent a few hours trying to get the integration working, but it just never did fully. For instance, it never picked up the Play libs and the dynamically generated code wasn't dynamically loaded by the debugger, etc. Maybe it was just something I was doing. But, after a while, when you're already unsure if you're going to like the framework, it's like, "nevermind. Back to work".


Scala as template language is totally optional. There are severals options: http://www.playframework.com/documentation/2.0.3/Modules


Thanks, actually I've waffled again, I'm still trying to make Play work for a test project on the side. It seems version 1 supported deployment to Tomcat but not 2. If I run Play as the server I guess it's not a big deal though.


> The problem I have with Play is that even their tutorial seems to me to try to brainwash you into getting into Scala

The problem with Grails is using Groovy is virtually mandatory. At least Play gives you a choice.


Is there something like "Learn Java in 15 minutes" for programmers knowledgeable in other languages? I'd like to see idioms, keywords, basic data structures described in a condensed form.



Thanks! Everything looks very familiar. Is that's all to know about Java (the language)?


Certainly not. To understand what's possible with Java (the language), you should look over the extensive API available for use as well. This is what you get for free with Java.

http://download.java.net/jdk8/docs/api/


I added the language because I am not interested in the libraries. I'm interested in the syntax and semantics.


Pretty much. If there's anything missing, you can usually assume C/C++ syntax. (reminder - no pointer distinctions in Java though)


I found this http://web.cecs.pdx.edu/~harry/musings/JavaLang.html. Looks comprehensive.


Basically it's saying the JVM is awesome.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: