Live data from Hacker News

What's new in Java 12, 13 and 14

java.christmas

91–100 of 136 posts

Re: What's new in Java 12, 13 and 14

#91
post #74
post #71

Earlier quoted context omitted.

Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does not matter. It may seem simple, but most implementations have that integer as part of the deployment path. The aggressive deprecation/removal in the 'major' six month cycle has been rough. If this is my local workstation, no worries. It creates chaos on work sys…

> six months is a ridiculous pace to package/distribute a new major version I agree, which is why we've done away with major releases altogether. There have been feature releases every six months with major new features for over ten years now. All that's changed is that we've changed how they're named and removed the major releases. And if you've found it acceptable that the 8u20 feature releases stopped getting patc…

> Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings.

If upgrading from one stable release to the next stable release removes features without a deprecation period, something's wrong with the release model.

Re: What's new in Java 12, 13 and 14

#92

Earlier quoted context omitted.

I hugely disagree with you thinking that event is useless in C#, rather I think it should have had been implemented as built-ins in every major programming language in the style of what C# did. Not only that it makes every possible event explicit and stand-out on its own, which is good for inline optimization and documentation (think about the catastrophic event handling in JS world), it also provides a standard, muc…

> it makes every possible event explicit and stand-out I agree that's nice to have - essentially announcing events as special in the type system. > good for inline optimization Any optimisation here should be possible with an ordinary implementation of the observer pattern, no? > it also provides a standard, much more intuitive syntax using formal function delegate declaration I'm not convinced that it does. Without…

I'd much rather use events than that snippet.

Re: What's new in Java 12, 13 and 14

#93
what's up with all these .christmas domains appearing high on HN listings?

there appear to be accounts dedicated to posting from javascript.christmas, java.christmas, and functional.christmas , all of the same style/format/etc.

the only posts they submit are from those domains. is this a coordinated boosting effort?

functional.christmas => https://news.ycombinator.com/submitted?id=bendiksolheim

javascript.christmas => https://news.ycombinator.com/submitted?id=ewendel

Re: What's new in Java 12, 13 and 14

#94
post #9

One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language conservative. This is because VM/library features have a much bigger impact on application quality, and more directly impact the application's users; moreover, it's a strategy that's proven quite successful -- HN notwithstanding, most developers don't like too m…

Language changes are super important when they enable you to program in a new way, or in that way with significantly less boilerplate. For instance, Java 8 enabled new ways of programming via Lambdas and structural typing. You could code in that way before, but anonymous class boilerplate was so high that few bothered, and those that did were hard-pressed to convince their colleagues of its value.

The problem with language changes is that to make use of them, your developer community has to educate themselves on the new features and how to use them. Certain VM changes like new GC algorithms often don't require this, as the basic interface of the GC is the same (clean up garbage for me, thanks!).

I think the next big programming style Java may enable is what I call data-oriented programming, which is enabled via sealed types and pattern matching. This enables you to code the dual of OO, where you have a fixed number of sub-types but an unbounded number of operations. I believe this style of programming is useful far more often than it is used, simply because Java doesn't make it easy to code in this style.

Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are:

* Improved native code interop. I consider this to be both a language and VM change. * Improved memory layout control, including stack-allocated types and inlined objects inside of other objects. * project loom for golang-style I/O programming. * full tail recursion. Why was this feature rejected from the VM?

Re: What's new in Java 12, 13 and 14

#95
post #32

Sigh, I know new language features are cool, but I highly doubt the growing dominance of Python and JS is a question primarily of language features. Python has a REPL and the outstanding tooling built on that along with an ecosystem of libraries where a default use case is the design choice. That all leads to "fast" development which what a lot of people care about. JS has the default use app deployment area: browser…

It's a different kind of programming. Two different industries basically.

Python and JS were designed for small experiments. I would wager 90% of Python code per capita are single file scripts.

Java is for building whole systems.

The reason Java is losing traction compared to the Python/JS type languages is that the type of programs people write are different. In the 90s, the majority of programming was on big infrastructural things like word processors, control software, web browsers, etc. Now that programming has gotten so much more popular, more people (by plurality) are working on comparatively smaller, more toyish things. It happens that Python/JS is the better tool for this kind of work.

If software is to keep growing at the same pace, the new programmers will be absorbed by the Python/JS camp. Python/JS will keep rising. There is a maximum number of kernel developers or compiler developers in the world, but the amount of small toy apps that can be created is infinite.

Re: What's new in Java 12, 13 and 14

#96

what's up with all these .christmas domains appearing high on HN listings? there appear to be accounts dedicated to posting from javascript.christmas, java.christmas, and functional.christmas , all of the same style/format/etc. the only posts they submit are from those domains. is this a coordinated boosting effort? functional.christmas => https://news.ycombinator.com/submitted?id=bendiksolheim javascript.christmas =…

Scroll down to the bottom of the page, it’s essentially a single website.

Re: What's new in Java 12, 13 and 14

#97
post #85
post #22

As someone that used to write a lot of C#, I find that the language is changing so often that it's hard to know what's new and what's been around for years. In contrast, Java hasn't changed all that much over the years, and I wonder if an approach of taking the more useful features from C# and ignoring some of the others would be a good approach. I often wonder how Java developers feel when they look over at C#, and…

> I often wonder how Java developers feel when they look over at C#, and see a language that has exploded in functionality over the last decade, all while Java has mainly optimised the JVM and slowly added features. I am a long time Java programmer that has mostly programmed C# lately. I'm getting more conservative by the years but I still found myself liking modern C#. The thing I miss from Java is the ecosystem: -…

Use Rider and Nuget and you shouldn't miss much.

Re: What's new in Java 12, 13 and 14

#98
post #73

Earlier quoted context omitted.

> It's taking features than have shown good cost/benefit, and not taking those that haven't. I actually wonder if it's more taking features that have proven sexy, and ignoring the rest. I still think that the single biggest source of verbosity - and design damage in some of the newer APIs such as streams - is that Java hasn't implemented extension methods. That costs me time and money on a regular basis. By compariso…

First, no language feature has been shown to move the needle much in terms of productivity or code quality. We are unable to detect differences between (reasonable) language choices, let alone individual features, so it's mostly about ergonomics. I'd be extremely surprised if you could show that any feature or lack thereof actually costs you money, but if you could, that would be quite a discovery. As to extension me…

> I'd be extremely surprised if you could show that any feature or lack thereof actually costs you money,

Bad language design and semantics definitely costs money in the long term. For example, Tony Hoare refers to Null References as his "billion dollar" mistake. The verbosity of Java before sophisticated IDEs would also have cost significant time and money. Java is improving significantly (and arguably was never as bad as say JavaScript or PHP), but there are some legacy decisions that will be very hard to change; and so improvement can only ever be incremental.

Re: What's new in Java 12, 13 and 14

#99
post #90

Earlier quoted context omitted.

I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative la…

The reluctance might be because polymorphism and pattern matching are kind-of solving the same problem from different angles.

That's not really true. OOP discourages inspecting the class of an instance, but still has conventional imperative control-flow. Deeply nested 'if' statements can rapidly become less readable than pattern-matching.

Re: What's new in Java 12, 13 and 14

#100
post #91
post #74

Earlier quoted context omitted.

> six months is a ridiculous pace to package/distribute a new major version I agree, which is why we've done away with major releases altogether. There have been feature releases every six months with major new features for over ten years now. All that's changed is that we've changed how they're named and removed the major releases. And if you've found it acceptable that the 8u20 feature releases stopped getting patc…

> Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings. If upgrading from one stable release to the next stable release removes features without a deprecation period, something's wrong with the release model.

No, stable releases do get deprecation warnings, but that's not what LTS is. LTS is a service that's added by vendors to arbitrarily chosen versions. In fact, there is no such thing as "an LTS release." You can start offering LTS for JDK 12 tomorrow, making it -- retroactively -- LTS. The OpenJDK development process doesn't take those services into account; in fact the development process has no notion of LTS at all (e.g. can you see LTS mentioned here https://openjdk.java.net/projects/jdk/11/ ?). All feature versions are equal in their stability. LTS is something a release can have, not something it is. All versions between 11 and 17 are stable, and none of them -- including 11 and 17 -- are major releases. Those are gone.

LTS is a service designed for organizations with special constraints, and should be no means be your default choice. Moreover, there are multiple LTS services and they differ quite widely in what they offer and who they're aimed at. Put simply, LTS does not mean what it means in other projects. Do not choose it until you've learned exactly what the new model means and what LTS means.

Post reply on HN