5 ms·

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

by doktrin 13y ago

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.

michaelwww 13y ago
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.
soemarko 13y ago
> 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.
jbooth 13y ago
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.
- barrkel 13y ago
  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.
  - saryant 13y ago
    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.
    - barrkel 13y ago
      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.
- doktrin 13y ago
  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.

by doktrin 13y ago

michaelwww 13y ago

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.

soemarko 13y ago

> 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.

jbooth 13y ago

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.

barrkel 13y ago
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.
- saryant 13y ago
  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.
  - barrkel 13y ago
    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.
doktrin 13y ago
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.