Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 12

jdk.java.net

Post reply on HN
Print view View original

371–380 of 478 posts

Re: Java 12

#371

Post by pjmlp »

merb wrote: post #331
ksec wrote: post #302

Earlier quoted context omitted.

>Google would have been a better steward, and probably would have been willing to pay more for the Java parts of Sun. They didn't and Google didn't want a pay a single dollar to Sun on Java. As James Gosling has mentioned multiple times. I don't understand why people are still painting Google as Saint after all these years.

actually they didn't want to pay a single dollar to sun, because of licensing reasons, not because they didn't wanted to buy java. currently they recreated the java apis by pulling in apache harmony and they tought that they are in the right or at least in a fair use position (they still think they do). but I agree, I'm not sure if the direction of java would've been better when google would have the stewardship.

They had the opportunity to buy Sun when it went on sale, instead they thought they could get away with it.

Re: Java 12

#372

Post by nickspacek »

vbsteven wrote: post #309
tannhaeuser wrote: post #301

Earlier quoted context omitted.

The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serving APIs (expressjs and core http request API, which expressjs middlewares forwards and decorates) is stable since node.js v0.1 or at least 2015, and infinitely better than Java's servlet, JSP, and taglib APIs (web.xml/jetty-config.xml anyone?). The flip side…

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.

Re: Java 12

#373

Post by schwurb »

tobiaswk wrote: post #354
MarkMc wrote: post #214

I'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 years like some flavour-of-the-month Javascript framework. Even on the client where Java has lost to Javascript, I'm finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javas…

I love Dart and Flutter. I actually think it was a good idea not to use Java. Dart is much more modern and nice to work with in my opinion. There are many reason and I won't dwell into it here. The biggest-ish project I've built with Flutter is an alternative to Nissan's ConnectEV app; it's used with the electric vehicles Nissan Leaf and Nissan E-NV200. You can see statistics, battery status and control climate contr…

I am currently building my first mobile app on Flutter and quite happy I choose that technology! Developing in AndroidStudio + Flutter does not feel like the chore I remember developing android apps to be.

Re: Java 12

#374

Post by jcadam »

Consultant32452 wrote: post #281
Justsignedup wrote: post #218

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 Streams and lambdas immediately, along with functional interfaces. Java is still not nearly as pleasant as Scala or Clojure, however.

Re: Java 12

#375

Post by aardvark179 »

hyperpallium wrote: post #264
aardvark179 wrote: post #197

Earlier quoted context omitted.

That kind of multiple dispatch would be far more disruptive at several levels, and still wouldn’t really get you where you want to go without a lot more compiler and JIT magic. Sure, you could match on types, but you wouldn’t be able to extend that to destructuring patterns, or regsxps as patterns on strings, or so many other ways patterns may be extended in future releases.

My comment's a little out of place. I'm not against pattern matching, but for double dispatch; we can have both. Their initial motivating examples was bare instanceof , but I now see they extend it. How would destructuring fit this model ?!

Brian Goetz has writes quite a bit about ongoing projects. The latest article he has done about pattern matching is I think http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.h.... There is a load of stuff in there about destructuring patterns from about half way down.

Re: Java 12

#376

Post by jacques_chester »

james_s_tayler wrote: post #282
samus wrote: post #99

Earlier quoted context omitted.

Yeah, that kinda makes it impossible to become a successor to Swing. But the situation actually got more sane because JavaFX can be included now as a Maven dependency, like any other framework.

Why do people still use Maven when Gradle exists? I'll never know.

Because there's only one syntax (yes, XML, but it's consistent), it's fast, the documentation is comprehensible, it has multi-project and multi-module support that is easy to understand, I lose track of what else.

Gradle is the worst allergic reaction to XML in history.

Re: Java 12

#377

Post by coldtea »

provolone wrote: post #370
tannhaeuser wrote: post #301

Earlier quoted context omitted.

The times of ever-changing JavaScript frontend frameworks is long behind us (and, arguably, React has won for MVw-style browser apps). The core node.js web serving APIs (expressjs and core http request API, which expressjs middlewares forwards and decorates) is stable since node.js v0.1 or at least 2015, and infinitely better than Java's servlet, JSP, and taglib APIs (web.xml/jetty-config.xml anyone?). The flip side…

Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks. Not sure where the 'over-engineered' view comes from. I'd call that 'sane'. People complain about the verbosity of Java, but how much time do you spend learning a new framework and all of the gotchas? At the end of the day it seems easier to just write the…

>Spring and other frameworks may be popular, but the base servlet api with db connection pooling is enough. This approach feels much lighter than using frameworks.

That. I've used the Servlets API for years in the early to late 00s.

I'm now (for the past 5 years) using Express with Node.

Static typing and cosmetic differences aside, Servlets and Express (or Node's raw handlers) are pretty much the same API.

Request, Response objects, handlers, middleware (iirc we used to call those last "filters" in the Servlet era), etc. It's not like it's some alien convoluted design.

(Java Server Faces now was another thing)

Re: Java 12

#378

Post by pjmlp »

kartickv wrote: post #252
azhenley wrote: post #6

The most interesting new feature I think is the Shenandoah GC. The summary from [1]: "Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB." The original algorithm…

Is there a guide to the various GC algorithms? Suppose I'm running an app where pause times don't matter, and I want throughout or reduced memory usage. How much more of this will I get by switching to another GC algorithm? 2%? 20%? 40%?

Mostly profiling.

Each JVM implementation (Azul, IBM, OpenJDK, PTC, Aicas,...) has their own collection of GC algorithms.

And their behaviour depends pretty much on the application as well.

Re: Java 12

#379

Post by coldtea »

tannhaeuser wrote: post #330
pjmlp wrote: post #314

Earlier quoted context omitted.

In all these years I have used Spring exactly once for an architecture prototype, during one month project. All our customers doing Java Web projects are either on JEE, or a CMS platform running on top of servlets and JEE related JSRs, like Liferay and AM.

I have no doubt it's working for you and your customers. But JEE and JSRs have been a dead end for many years now. When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it? In 2006 I played around with Jackrabbit for an architecture concept (for managing airworthiness of airplanes and kit). That was before the Iphone even existed. I was honestly surpri…

>When there are only single implementations for JSRs left, the whole exercise becomes pointless and masochistic, doesn't it?

Not any more than PEPs are.

Re: Java 12

#380

Post by coldtea »

Justsignedup wrote: post #218
MarkMc wrote: post #214

I'm so glad I was taught Java at Macquarie University back in 1998. For the past 20 years I've had a career built on a solid API that doesn't change every 2 years like some flavour-of-the-month Javascript framework. Even on the client where Java has lost to Javascript, I'm finding it more enjoyable to add features to my 15-year-old SWT app [0] rather than dealing with the multiple layers of abstractions that is Javas…

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.

>java is a stable api but it also doesn't evolve

You have probably missed the last 5 years. From streams, to closures, to default methods, to functional interfaces, to local type inference, to new Process APIs, to modules, to unsigned arithmetic, to new date/time APIs, http client, 2 new GCs, shell REPL, etc... with more to come, and new releases every 3 months...

Post reply on HN