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

421–430 of 478 posts

Re: Java 12

#421

Post by abalone »

pjmlp wrote: post #321
abalone wrote: post #95

Earlier quoted context omitted.

How is memory efficiency? Usually faster and/or consistent GC performance comes at the cost of extra memory usage. (This is why I'm excited for ARC / Swift on the server...)

Go and C# running circles around Swift. "35C3 - Safe and Secure Drivers in High-Level Languages" https://www.youtube.com/watch?v=aSuRyLBrXgI

Well, not exactly C#. At 39:00 they show significant latency problems with C#’s garbage collector. Go and Rust did well though.

Will be interesting to see if ARC gets optimized for use cases like this (drivers). I wouldn’t say it’s super representative of general server programming though. And unless I missed it I don’t think they compared memory footprint.

Re: Java 12

#422

Post by pjmlp »

coldtea wrote: post #416
pjmlp wrote: post #412

Earlier quoted context omitted.

I guess Fortune 500's have missed that memo, including IBM own subsidiaries. Lets talk back in 5 years from now. I am betting Kotlin would become yet another language that happens to compile to the JVM, after the Android honeymoon goes away.

> I guess Fortune 500's have missed that memo, including IBM own subsidiaries. They probably did. They're late for all memos. The Fortune 500 is not were you'll go to gauge adoption. Heck, half of them still have IE6 only apps. There are hundreds of thousands of companies, and just 500, well, Fortune 500. Apparently you use the most established and boring development-wise of companies (Fortune 500) to prove Kotlin is…

Because they prove Google is struggling with internal politics where to go next.

Re: Java 12

#423

Post by spricket »

scarface74 wrote: post #415
spricket wrote: post #413

Earlier quoted context omitted.

It's not built in to the language, but JOOQ and QueryDSL come fairly close. I do miss LINQ though. The Java options are all clunkier because the type system isn't nearly as flexible

I can't tell from looking at the examples, but can I do things like pass around arbitrary expressions: Person.Get(p => (p.Age > 65 && p.Sex == "M") || (p.Age > 63 && p.Sex == "F")) and have a method public List Get(Expression > expression) and have that expression interpreted correctly at run time by separate providers? You get full compile time checking and IDE supported autocomplete.

Yes. But it's done in a different way than C#. C# supports fields and field references so you can pass them directly to a function.

The Java code "looks" like they do the same because they generate code to simulate method references instead. It's pretty clever and Javas code generation support for Annotation Processors is excellent and makes it possible to do this in a cross-ide cross-build-system way

LINQ and JOOQ/QueryDSL all work on plain data objects with fields. But with Java you do it on a pseudo object generated from your existing classes

Re: Java 12

#424

Post by scarface74 »

spricket wrote: post #423
scarface74 wrote: post #415

Earlier quoted context omitted.

I can't tell from looking at the examples, but can I do things like pass around arbitrary expressions: Person.Get(p => (p.Age > 65 && p.Sex == "M") || (p.Age > 63 && p.Sex == "F")) and have a method public List Get(Expression > expression) and have that expression interpreted correctly at run time by separate providers? You get full compile time checking and IDE supported autocomplete.

Yes. But it's done in a different way than C#. C# supports fields and field references so you can pass them directly to a function. The Java code "looks" like they do the same because they generate code to simulate method references instead. It's pretty clever and Javas code generation support for Annotation Processors is excellent and makes it possible to do this in a cross-ide cross-build-system way LINQ and JOOQ/Q…

That's really interesting.

All of these years I've been beating up on Java for lack of something akin to LINQ. I guess I'll have to find something else to complain about.....

Re: Java 12

#425

Post by ivan_gammel »

tannhaeuser wrote: post #333
ivan_gammel wrote: post #317

Earlier quoted context omitted.

Any app reaching complexity of what’s being done on Java will look the same, no matter what platform do you choose. I haven’t yet seen large nodejs deployments with MLOCs and hundreds of developers, but I’m pretty sure it can easily become much bigger mess - the tools and the libraries are immature, there’s lack of enterprise SDLC patterns etc, which creates a lot of obstacles. Spring is becoming too enterprisey thes…

nodejs isn't a replacement for fat backends for sure, but it's working really well for a frontend-facing light backend where frontend developers can add endpoints as the need arises, such as for autocomplete functionality, and where first-party support for asset pipeline tools is desired. The Spring experience isn't bad for newbies creating "REST" microservice spaghetti to have something to show at the end of their a…

I‘m seasoned dev with 20 years of Java programming experience, I see no problems using Spring and I don’t see why anyone with similar experience would have any. It’s sometimes not obvious, how some things work, but it’s open source and the code is quite good to analyze, extend or replace.

Re: Java 12

#426

Post by jimbokun »

nickspacek wrote: post #372
vbsteven wrote: post #309

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.

"Spring/Spring Boot hides that complexity"

Until it doesn't, then everything goes to Hell very quickly.

Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it.

Program logic is defined in anything and everything, except actual Java code.

The whole thing is a nightmare ignoring every principle of simplicity, composability, referential transparency, and every other established principle of good software design.

Re: Java 12

#427

Post by jimbokun »

lmm wrote: post #349
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…

> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming. There was definitely an era of that, but over the past decade or so it's been acknowledged as a problem, and there's been a lot of effort put into making things simpler and more vanilla. Modern Spring is much much closer to plain old code. (Of cours…

"Modern Spring is much much closer to plain old code."

Modern Spring, as far as I can tell, is still very much driven outside of Java code, it's just migrated from XML to annotations and yaml properties files. Seems almost like the typical Spring application has more lines of annotations and properties files than lines of Java code.

I am fond of Maven, though, especially with Gradle (superior to pom files).

Re: Java 12

#428

Post by jimbokun »

ivan_gammel wrote: post #425
tannhaeuser wrote: post #333

Earlier quoted context omitted.

nodejs isn't a replacement for fat backends for sure, but it's working really well for a frontend-facing light backend where frontend developers can add endpoints as the need arises, such as for autocomplete functionality, and where first-party support for asset pipeline tools is desired. The Spring experience isn't bad for newbies creating "REST" microservice spaghetti to have something to show at the end of their a…

I‘m seasoned dev with 20 years of Java programming experience, I see no problems using Spring and I don’t see why anyone with similar experience would have any. It’s sometimes not obvious, how some things work, but it’s open source and the code is quite good to analyze, extend or replace.

"the code is quite good to analyze, extend or replace"

But how do you even know what code to read when so much of the program's logic is in annotations and other kinds of action at a distance?

Re: Java 12

#429

Post by apta »

tannhaeuser wrote: post #301
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…

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…

> On the server-side, customers use mostly Spring/Spring Boot these days to make Java's overengineered stack usable, using even more over-engineering and metaprogramming.

Could you elaborate on the overengineering part? There are many modern frameworks that are much lighterweight than Spring/Spring Boot, and with the introduction of lambdas in Java, things are even more straightforward.

Also, gradle doesn't use XML.

Re: Java 12

#430

Post by _bxg1 »

nineteen999 wrote: post #328
pjmlp wrote: post #91

Earlier quoted context omitted.

Once upon a time the barrier was the existance of VMT tables and method dispatch. GC use can be optimized in high level languages with support for value types (which are still missing in Java, though) and it is not like every game needs to be the next Fortnight.

Only tangentially related to your comment, Fortnite is based on UE4 so it does use garbage collection. And it has caused framerate/hitching issues as recently as a year ago according to an Epic developer. https://www.reddit.com/r/FortNiteBR/comments/7gu8aq/hitching...

I didn't realize UE4 adds a garbage collector on to C++. Interesting.
Post reply on HN