The Rise and Fall and Rise of Java [video]
marakana.com
marakana.com
* 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.
Have yet to watch the video, but my biggest problem with Java was THE language and swing.
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.
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.
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.
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.
> 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).
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.
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.
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.
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.
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.
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?
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!
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.
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."
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.
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.
Also, feel free to check out Nitro, a low level functional programming language.
http://homepages.inf.ed.ac.uk/stg/workshops/TFP/papers/Clark...
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 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.
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.
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.
who's there?
(long wait)
Java.
That's what we decided!
And now that's what we do.
Horstmann wrote "Scala for the Impatient" (great book) and presents the issues around the language and tooling pretty fairly
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.
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.
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).
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
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.
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.
Partially joking of course -- however my experience with Oracle has not been pleasant (with the exception of VirtualBox).
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.
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.
So, in some senses, at least the rabid drive toward implementing the full spec has been deprecated, if not the technology itself.
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.
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-...
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 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.
The problem with Grails is using Groovy is virtually mandatory. At least Play gives you a choice.