8 ms·

While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its

While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative points? But Java's recent and upcoming additions show _taste_: adopting a single lambda notation that fitted smoothly with the surrounding class-based OOP paradigm via SAM types (rather than magically-generated-type-style lambdas succeeding two overlapping "delegate"/"event"-like features); implementing (sadly somewhat-incompatible) modules that can curtail unbounded reflection, opening the door to greater reasonability and performance in the future; proposing Project Loom to avoid the async/sync API split that hit Python, C#, and even Kotlin Coroutines; and now Valhalla, which was quietly mulled on for years before arriving at this very reasonable solution that considers myriad angles. I like this approach to language design and think it bodes well for the language's future. It's a sweet spot between being necessarily conservative, dealing with developers' real-world problems, and giving time to mull over new language feature designs and not just implementing as soon (and haphazardly) as possible to please vocal developers.

billfruit 7y ago
While that is interesting to hear, is there a single book that brings someone who hasn't used Java in the last 5 years upto speed, like the book Bjarne Stroustroup's 'A tour of c++' does for c++.
- zelly 7y ago
  I think the Java Language Specification is very readable (and up-to-date and without useless narrative glue that's in regular books).
- pas 7y ago
  Book? Basically a few presentations from previous years of Java conferences is all you need. But even faster is just looking through the release notes for the major versions. https://en.m.wikipedia.org/wiki/Java_version_history https://en.m.wikipedia.org/wiki/Java_version_history
- ljackman 7y ago
  There might be, but unfortunately I don't know it. I learnt Java initially from the first edition of Just Java, read from various other sources about the 1.5 and 1.6 additions it didn't cover, and then learned new features from OpenJDK proposals from 1.7 onwards as they were released. The biggest impact of the 5 years for working developers has probably been: * Streaming API and lambdas allowing usual `map`/`filter`/`reduce` transformation pipelines line many other languages (lazy, unlike JS's `Array` methods, parallelism considered via "spliterators" unlike Python). * Default methods in interfaces, _not_ making them traits, but arguably more "trait-like". It allowed them to add many useful methods onto existing types without needing bifurcate the common APIs. * A REPL. Probably not a big deal for a professional developer, who likely uses IntelliJ's "Evaluate Expression" feature already for a similar feature, but pretty useful for education I guess. * Better at being stuffed inside Docker containers with resource limits. Also, max permgen space no longer a problem really (it's where you had to set an upper memory limit when invoking Java programs, which was annoying). Just generally less annoying at being deployed in modern infrasructures. * APIs like `File.lines` that mean you don't need to recite War and Peace just to do a buffered operation across lines in a file. Generally more ergonomic APIs that finally make basic operations sane. * Type inference with `var`. Basically the same as C#'s `var` or Go's `:=`. * More native executable-producing tooling. jlink, jpackager, etc. The dream of ubiquitous, shared Java runtimes installed everywhere didn't really work out, and they seem to have realised that. * Ecosystem moving away from XML. Still there, just less common. Runtime annotations are used more heavily, which I'm honestly not sure is a massive improvement. Hopefully more lambda-heavy APIs will reduce use of runtime annotations; see Spring WebFlux's functional handlers for annotation-based controllers for a comparison. There's a lot more, but I'd argue it won't be as immediately visible for the working developer more than those points. Modules were important for the ecosystem, but most devs probably aren't worrying about that day-to-day. Gradle and Maven still dominate the building/packaging side.
  - billfruit 7y ago
    Very informative summary, thank you.
BoorishBears 7y ago
I would agree with this if C# didn't definitively show you can have a successful enterprise/"LTS" language that doesn't move at a glacial pace and spend several years doing little to nothing (pre Java 8) It's implemented features Java had just gotten much earlier, in much more useful forms (see: generics, lambdas) without them being "haphazard" about it. - To me tasteful is what C# did, breaking changes when needed, but only when so much value was added no one could be upset with the result. It takes way more effort, and way more carefulness than "we're going to move at glacial pace and provide half-hearted features in the name of backwards compatibility" (again, see: lambdas and generics)
- ljackman 7y ago
  These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` and `out` parameters to appease archaic COM APIs. * Tuple unpacking, which makes sense independently but then bizzarely tries to integrate with `out` parameters. * A nice "ex nihlo" object literal syntax that shoots itself in the foot by undermining immutability due to requiring settable fields. (TBF, later versions fixed this IIRC.) * Inline functions in methods in a language that already has lambdas and methods; it's just bloat. * `as` casting that yields nulls. Did it really need a whole new syntax just to handle null more concisely specifically for casting? * `partial` classes. Encouraging even more code generation with features like this is a questionable idea and wasn't necessary in other languages. * `dynamic`. Even if there are use cases for it, it's strange in an otherwise static language with a top-level Object type anyway. I'm saying this as someone who's perfectly happy with fully dynamic languages like Erlang and Lisp. I just don't see the point of adding it to C# specifically. * C-style enumerations. * Properties. Invoking side-effects on something that is syntactically indistinguishable from an attribute read is a bad idea. Auto-generation of Java's verbose getters would be long overdue, but the caller site shouldn't be the same a la C#. * Extension methods. It seems quite ad hoc compared to static addition of types to common operations in other languages, like imported traits in Rust or typeclasses in Haskell. * Proposed "shapes". Looks like a good idea by itself but will overlap too much with default method implementation and other existing mechanisms. * Interfaces prefixed with `I`. Not strictly a language problem but an ecosystem one. I shouldn't need to know what _sort_ of type I'm dealing with, that's '90s Hungarian notation. * Nullable reference types. Getting rid of null is good, but this proposal became confusing. They mentioned opting in assembly-wide for a while but there was then a conversation about having it just warn in some cases. I need to read the latest literature around this, but it seemed less elegant than Java just adding a monad-like Optional type and not adding loads of special-case operations with question marks everywhere. Despite this, I still admire a lot of the design decisions behind C#. LINQ was great. `async/await`, despite my belief of its inferiority to Goroutines/Project Loom/Erlang processes, was still a great innovation from Midiori at the time. Value types were obviously right to be implemented early on. Assemblies were a good idea. Private by default rather than package-accessibility was a nice touch, as was the `override` keyword. The C# team are smart people who know what they are doing! As an aside, I used to be firmly against erased generics, but reading more about the tradeoffs from the likes of Gilad Bracha has caused me to reconsider.
jshore 7y ago
The .NET CLR (VM) has had proper generics and value types since 2002. Java did not implement generics until 2004 and to this day does not have user-defined value types. There was an opportunity to do it right in 2004 before this became "baked in". There is really no good excuse. Many developers have abandoned java due to the glacial progress with both the language and the VM. It is legacy now. The main benefit (IMO) of Vahala would be for other JVM languages (such as Kotlin) to make the implementation of value types more efficient. (I use both CLR and JVM in my work, but is clear to me that the CLR is superior on many fronts).
- pron 7y ago
  Well, some companies still write many of their new projects in the Java language (not to mention use the Java platform), like Apple, Amazon, Alibaba, Google, Netflix, and, of course, banks, governments, airports, militaries, hospitals, utility companies, factories, robotic warehouses [1], and most Fortune 500 companies. [1]: https://www.infoq.com/presentations/java-robot-swarms/ https://www.infoq.com/presentations/java-robot-swarms/
  - discreteevent 7y ago
    To make your comment more explicit: The parent states that Java is legacy now. But given your examples above that would mean that java and many other languages are legacy now. Of course any language could be legacy in the future but historically the probability that one of those future legacies is a hot new language now is at least equal with that of an established language currently still widely used to write significant production software.
    - pron 7y ago
      There are very few languages (two at most) used to write more new software now than Java.
choppaface 7y ago
It’s interesting to look at this celebratory narrative and the fact that Valhalla took over 5 years (!?). And contrast with the rise of go and AWS Lambda. And C++, where the polished parts of boost got added to the language behind some flags (so the old language was preserved). And the growth of C++ despite the complete absence of a competitive, platform agnostic packaging & distribution solution. Wait, why do we care about the JVM?? This whole article appears to address concerns that, while fundamental to programming, are also fundamentally irrelevant to shipping products.
- humanrebar 7y ago
  > ...complete absence of a competitive, platform agnostic packaging & distribution solution Well, to be fair, it's more like there are two (or so) good cross platform ones at the moment, but there isn't one so popular to be de facto. And there isn't one that is standard. Besides, the most popular packaging and distribution systems for native code might still be the popular Linux distros. Packaging and distributing precompiled binaries with native ABIs (not targeting interpreters or runtimes) is much more complicated. Folks have decided to value other things than portability of packages for now. That could change in the future.

billfruit 7y ago

While that is interesting to hear, is there a single book that brings someone who hasn't used Java in the last 5 years upto speed, like the book Bjarne Stroustroup's 'A tour of c++' does for c++.

zelly 7y ago
I think the Java Language Specification is very readable (and up-to-date and without useless narrative glue that's in regular books).
pas 7y ago
Book? Basically a few presentations from previous years of Java conferences is all you need. But even faster is just looking through the release notes for the major versions. https://en.m.wikipedia.org/wiki/Java_version_history https://en.m.wikipedia.org/wiki/Java_version_history
ljackman 7y ago
There might be, but unfortunately I don't know it. I learnt Java initially from the first edition of Just Java, read from various other sources about the 1.5 and 1.6 additions it didn't cover, and then learned new features from OpenJDK proposals from 1.7 onwards as they were released. The biggest impact of the 5 years for working developers has probably been: * Streaming API and lambdas allowing usual `map`/`filter`/`reduce` transformation pipelines line many other languages (lazy, unlike JS's `Array` methods, parallelism considered via "spliterators" unlike Python). * Default methods in interfaces, _not_ making them traits, but arguably more "trait-like". It allowed them to add many useful methods onto existing types without needing bifurcate the common APIs. * A REPL. Probably not a big deal for a professional developer, who likely uses IntelliJ's "Evaluate Expression" feature already for a similar feature, but pretty useful for education I guess. * Better at being stuffed inside Docker containers with resource limits. Also, max permgen space no longer a problem really (it's where you had to set an upper memory limit when invoking Java programs, which was annoying). Just generally less annoying at being deployed in modern infrasructures. * APIs like `File.lines` that mean you don't need to recite War and Peace just to do a buffered operation across lines in a file. Generally more ergonomic APIs that finally make basic operations sane. * Type inference with `var`. Basically the same as C#'s `var` or Go's `:=`. * More native executable-producing tooling. jlink, jpackager, etc. The dream of ubiquitous, shared Java runtimes installed everywhere didn't really work out, and they seem to have realised that. * Ecosystem moving away from XML. Still there, just less common. Runtime annotations are used more heavily, which I'm honestly not sure is a massive improvement. Hopefully more lambda-heavy APIs will reduce use of runtime annotations; see Spring WebFlux's functional handlers for annotation-based controllers for a comparison. There's a lot more, but I'd argue it won't be as immediately visible for the working developer more than those points. Modules were important for the ecosystem, but most devs probably aren't worrying about that day-to-day. Gradle and Maven still dominate the building/packaging side.
- billfruit 7y ago
  Very informative summary, thank you.

BoorishBears 7y ago

I would agree with this if C# didn't definitively show you can have a successful enterprise/"LTS" language that doesn't move at a glacial pace and spend several years doing little to nothing (pre Java 8) It's implemented features Java had just gotten much earlier, in much more useful forms (see: generics, lambdas) without them being "haphazard" about it. - To me tasteful is what C# did, breaking changes when needed, but only when so much value was added no one could be upset with the result. It takes way more effort, and way more carefulness than "we're going to move at glacial pace and provide half-hearted features in the name of backwards compatibility" (again, see: lambdas and generics)

ljackman 7y ago
These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` and `out` parameters to appease archaic COM APIs. * Tuple unpacking, which makes sense independently but then bizzarely tries to integrate with `out` parameters. * A nice "ex nihlo" object literal syntax that shoots itself in the foot by undermining immutability due to requiring settable fields. (TBF, later versions fixed this IIRC.) * Inline functions in methods in a language that already has lambdas and methods; it's just bloat. * `as` casting that yields nulls. Did it really need a whole new syntax just to handle null more concisely specifically for casting? * `partial` classes. Encouraging even more code generation with features like this is a questionable idea and wasn't necessary in other languages. * `dynamic`. Even if there are use cases for it, it's strange in an otherwise static language with a top-level Object type anyway. I'm saying this as someone who's perfectly happy with fully dynamic languages like Erlang and Lisp. I just don't see the point of adding it to C# specifically. * C-style enumerations. * Properties. Invoking side-effects on something that is syntactically indistinguishable from an attribute read is a bad idea. Auto-generation of Java's verbose getters would be long overdue, but the caller site shouldn't be the same a la C#. * Extension methods. It seems quite ad hoc compared to static addition of types to common operations in other languages, like imported traits in Rust or typeclasses in Haskell. * Proposed "shapes". Looks like a good idea by itself but will overlap too much with default method implementation and other existing mechanisms. * Interfaces prefixed with `I`. Not strictly a language problem but an ecosystem one. I shouldn't need to know what _sort_ of type I'm dealing with, that's '90s Hungarian notation. * Nullable reference types. Getting rid of null is good, but this proposal became confusing. They mentioned opting in assembly-wide for a while but there was then a conversation about having it just warn in some cases. I need to read the latest literature around this, but it seemed less elegant than Java just adding a monad-like Optional type and not adding loads of special-case operations with question marks everywhere. Despite this, I still admire a lot of the design decisions behind C#. LINQ was great. `async/await`, despite my belief of its inferiority to Goroutines/Project Loom/Erlang processes, was still a great innovation from Midiori at the time. Value types were obviously right to be implemented early on. Assemblies were a good idea. Private by default rather than package-accessibility was a nice touch, as was the `override` keyword. The C# team are smart people who know what they are doing! As an aside, I used to be firmly against erased generics, but reading more about the tradeoffs from the likes of Gilad Bracha has caused me to reconsider.

jshore 7y ago

The .NET CLR (VM) has had proper generics and value types since 2002. Java did not implement generics until 2004 and to this day does not have user-defined value types. There was an opportunity to do it right in 2004 before this became "baked in". There is really no good excuse. Many developers have abandoned java due to the glacial progress with both the language and the VM. It is legacy now. The main benefit (IMO) of Vahala would be for other JVM languages (such as Kotlin) to make the implementation of value types more efficient. (I use both CLR and JVM in my work, but is clear to me that the CLR is superior on many fronts).

pron 7y ago
Well, some companies still write many of their new projects in the Java language (not to mention use the Java platform), like Apple, Amazon, Alibaba, Google, Netflix, and, of course, banks, governments, airports, militaries, hospitals, utility companies, factories, robotic warehouses [1], and most Fortune 500 companies. [1]: https://www.infoq.com/presentations/java-robot-swarms/ https://www.infoq.com/presentations/java-robot-swarms/
- discreteevent 7y ago
  To make your comment more explicit: The parent states that Java is legacy now. But given your examples above that would mean that java and many other languages are legacy now. Of course any language could be legacy in the future but historically the probability that one of those future legacies is a hot new language now is at least equal with that of an established language currently still widely used to write significant production software.
  - pron 7y ago
    There are very few languages (two at most) used to write more new software now than Java.

choppaface 7y ago

It’s interesting to look at this celebratory narrative and the fact that Valhalla took over 5 years (!?). And contrast with the rise of go and AWS Lambda. And C++, where the polished parts of boost got added to the language behind some flags (so the old language was preserved). And the growth of C++ despite the complete absence of a competitive, platform agnostic packaging & distribution solution. Wait, why do we care about the JVM?? This whole article appears to address concerns that, while fundamental to programming, are also fundamentally irrelevant to shipping products.

humanrebar 7y ago
> ...complete absence of a competitive, platform agnostic packaging & distribution solution Well, to be fair, it's more like there are two (or so) good cross platform ones at the moment, but there isn't one so popular to be de facto. And there isn't one that is standard. Besides, the most popular packaging and distribution systems for native code might still be the popular Linux distros. Packaging and distributing precompiled binaries with native ABIs (not targeting interpreters or runtimes) is much more complicated. Folks have decided to value other things than portability of packages for now. That could change in the future.