Live data from Hacker News

Java 12

jdk.java.net

391–400 of 478 posts

Re: Java 12

#391

I understand why Java has to keep on chugging along, but I feel bad for the people that have to be a part of it. It's like watching people keep coal trains going while people are moving to cars. Why? Besides being owned by Oracle, which is enough of a reason to never use Java ever again, it's also lost the niches that brought it into existence. Java no longer runs everywhere. Java on the web is dead, and you can now…

That's an impressive rant and can't disagree with some of it, but you're nearly a decade behind in your assessment of java in the Enterprise. New deployments of EJB apps have dropped precipitously (never should have existed), and Java still enjoys wide Enterprise use. Part of the reason big businesses were able to abuse enterprises with their abominable Java server stacks is because corporations were slow to trust op…

The large majority of enterprises I work with use both, depending on the use case.

Re: Java 12

#392
post #315

Earlier quoted context omitted.

I am betting Kotlin is the new Groovy. Lets see where it stands 5 years from now, specially if Fuchsia actually gets released.

Groovy was a random JVM-based dynamic language with no major company support and no special tooling. Kotlin has IntelliJ (and thus a great IDE) and Google standing behind it, and Steve Yegge's nod of approval.

Not every Java shop is going to drop Eclipse and Netbeans just to make JetBrains happy.

As for Android, lets see what happens with Fuchsia.

The overwhelming majority of Java developers don't even know who Steve Yegge is.

Re: Java 12

#393
post #351

Earlier quoted context omitted.

What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Still not able to use several of Android Studio features available to Java, like incremental compilation and slim APKs? Kotlin advocates seem to forget JVM will never be rewritten in Kotlin, the language is just yet another guest, with the usual syndrome to wrap existing libraries, having to take care about FFI for Java acc…

> What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Seeing that both Eclipse and Netbeans are now more or less dead (and speaking as a long time Eclipse user, from the very first version to around 4), yes, first class vendor-direct InteliJ support is more than enough. And more than most languages (including Groovy) ever had. > As for Kotlin/Native, there is nothing to worr…

Groovy had Netbeans and Eclipse support, which was dropped when it started fading away.

We move in different worlds, no InteliJ installations around here.

I remember when Groovy was popular, with every JUG in Germany having weekly talks and Sun talking how the next JEE revision would support Groovy for writing beans.

Popularity doesn't write software.

Re: Java 12

#394

Earlier quoted context omitted.

You can call Spring (boot) over-engineered. I call it feature full and extensible. Whereas in the modern JS world, you start out with a lean project and then add small libraries from NPM that all work slightly different for every feature you need, in the Spring world where the framework has matured for 10+ years most of the things you will need are in the box or are available as external libraries that all work on th…

Actually they just said that Java's server-side stack is overengineered, and that Spring/Spring Boot hides that complexity. I think that is mostly true.

Parent said that Spring Boot accomplishes that with more over-engineering and metaprogramming. I wanted to point out that what parent calls over-engineering is actually useful abstractions that make it easy to get started out of the box, and have sane standardized interfaces to replace or integrate components where needed.

Re: Java 12

#395

Earlier quoted context omitted.

just had this conversation with a co-worker today. java is a stable api but it also doesn't evolve. The tradeoff is you get a program guaranteed to work no matter the upgrade vs being able to build better toolage. React changes every year or 2. It is exhausting. But you get way better patterns and some things that drastically improve productivity.

I've been working professionally in Java for almost 20 years. I can't remember the last time I saw someone use features introduced after 1.6. The time API in 1.8 was nice. I've never seen anyone use lambdas in production code. I'm sure people do use newer stuff, but I think it's the minority. So in practice it's even more stable than it is in the headlines.

We start using new features pretty much as soon as the new JDK version is released to general use.

Re: Java 12

#396
post #299

Earlier quoted context omitted.

I've been working professionally in Java for almost 20 years. I can't remember the last time I saw someone use features introduced after 1.6. The time API in 1.8 was nice. I've never seen anyone use lambdas in production code. I'm sure people do use newer stuff, but I think it's the minority. So in practice it's even more stable than it is in the headlines.

I work for a large company and the code base is full of streams and lambdas. Streams are almost used too much and could be replaced with a simple for-loop.

Yeah, stream overuse is definitely an issue at our company.

Re: Java 12

#397

Earlier quoted context omitted.

just had this conversation with a co-worker today. java is a stable api but it also doesn't evolve. The tradeoff is you get a program guaranteed to work no matter the upgrade vs being able to build better toolage. React changes every year or 2. It is exhausting. But you get way better patterns and some things that drastically improve productivity.

I've been working professionally in Java for almost 20 years. I can't remember the last time I saw someone use features introduced after 1.6. The time API in 1.8 was nice. I've never seen anyone use lambdas in production code. I'm sure people do use newer stuff, but I think it's the minority. So in practice it's even more stable than it is in the headlines.

I started using them ASAP.

Re: Java 12

#398
post #158

Earlier quoted context omitted.

We should print out copies of this comment, and laminate them, and give them to anyone who thinks that comments on HN are good, as an educational resource.

Limiting personal freedom is what the enterprise Java ecosystem is all about.

This is why people are calling you a zealot.

Re: Java 12

#399
post #393

Earlier quoted context omitted.

> What tooling? Being forced to use InteliJ, without any proper support on Eclipse and Netbeans? Seeing that both Eclipse and Netbeans are now more or less dead (and speaking as a long time Eclipse user, from the very first version to around 4), yes, first class vendor-direct InteliJ support is more than enough. And more than most languages (including Groovy) ever had. > As for Kotlin/Native, there is nothing to worr…

Groovy had Netbeans and Eclipse support, which was dropped when it started fading away. We move in different worlds, no InteliJ installations around here. I remember when Groovy was popular, with every JUG in Germany having weekly talks and Sun talking how the next JEE revision would support Groovy for writing beans. Popularity doesn't write software.

I don't understand how Groovy is fading away when it is getting more and more popular. Groovy is also very similar to Java. There is no learning curve, you are immediately creating value.

Re: Java 12

#400
post #83

Earlier quoted context omitted.

> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin. Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it…

No idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH. Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy

Groovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension
Post reply on HN