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

341–350 of 478 posts

Re: Java 12

#341

Post by thecleaner »

BinaryIdiot wrote: post #294
gigatexal wrote: post #283

Earlier quoted context omitted.

Biggest barrier to entry for me is the build dependency system Maven. And I never understood Ant. I did like the language when I played around with Java 8. Streams are amazing.

Maven is an incredible system. It can do so much and yet, even though I've setup countless apps and services, I can never use it without looking literally everything up. Maven and spring are the worst parts, for me, when dealing with Java. I don't mind the language at all.

What was your problem specifically ? For me these two worked great together actually. I really loved Spring. Maybe the problem has some overlooked fix that I can help with ?

Re: Java 12

#342

Post by Traubenfuchs »

spricket wrote: post #147
ilovecaching wrote: post #22

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…

I'm not sure if you're trolling so I'll try to keep this short. Java is old, it's crufty. Yes. But it's extremely fast compared to anything but Go, C#, and "low level" languages nobody wants to touch for web stuff. The JVM is also extremely reliable. I've seen apps run for years straight. And the tooling is better than basically anything. Profiling, debugging, realtime code generation and modification. Libraries for…

Spring Boot is all but dated. I could name you countless huge companies using Spring Boot to write new applications that will be used by millions of people per day in Austria alone.

Re: Java 12

#343

Post by vbezhenar »

nileshk wrote: post #202
vbezhenar wrote: post #59

Earlier quoted context omitted.

So far I did not find anything comparable to replace Java for website server language. Go is a terrible extremely verbose language without vital features. JavaScript on Node is limited by single-thread and JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby). Rust is awesome, but I don't think that it'll be ever usable for mediocre developers, therefore it can't b…

Assuming you meant specifically the Java language, Kotlin for JVM may also be a good option. Solid set of language features that puts it at least on par with C#, and allows you to write more DRY code than you can with Java language. As with any JVM language, you get all the benefits of the JVM. IDE support is great (at least with IntelliJ IDEA). It's an officially supported Android development language, putting it fu…

Yeah, I mean all Java ecosystem and I, personally, prefer Kotlin too.

Re: Java 12

#344

Post by vbezhenar »

hactually wrote: post #164
vbezhenar wrote: post #59

Earlier quoted context omitted.

So far I did not find anything comparable to replace Java for website server language. Go is a terrible extremely verbose language without vital features. JavaScript on Node is limited by single-thread and JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby). Rust is awesome, but I don't think that it'll be ever usable for mediocre developers, therefore it can't b…

Bit of a Go fan here so just wondered if you'd qualify what you mean by: > without vital features

Error handling via exceptions and generics are things that I can't live without. Go moves in that direction, as far as I understand, generics are expected in the next versions of Go and error handling somewhat improved, so may be it'll be good enough after few years, but I just can't write current Go after Java, it's like running with chained legs.

Re: Java 12

#345

Post by sourcesmith »

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…

Bad decisions can be made using any technology. Java has a lot of crufty legacy APIs because, well it has a legacy. I gave up using JSPs years ago for Freemarker. I now use Vert.x rather than servlet contains which gives me a node.js environment but with access to the Java ecosystems and basic things like mature logging frameworks, as well as more advanced features (oh and multithreading in a single process).

Despite Spring being Enterprise it still scales down to simpler apps pretty well due to its modularity.

These can be build into a single jar app that is easy to build and deploy, and combined with a database migration library, maintain their own database schemas. Very, very usable.

Yes, I probably would not use Java on the frontend unless it was for a technical audience.

Re: Java 12

#346

Post by pjmlp »

james_s_tayler wrote: post #334
pjmlp wrote: post #323

Earlier quoted context omitted.

Because Maven doesn't require a background daemon eating 2GB of memory to be fast and IDEs can actually provide code completion and documentation while typing. Android is the only reason to have to put up with Gradle.

Fair enough. It doesn't sell me on switching back to Maven. Ram is cheap enough. With 32GB Gradle can have a couple if it wants.

Most dev laptops are still running with 8GB.

2GB for a cache that isn't required by alternatives for the same result just feels bad.

And don't get me started into turning build scripts into full blown applications impossible to decipher what is going on without some kind of debugging process.

Re: Java 12

#347

Post by zmmmmm »

spricket wrote: post #233
vorg wrote: 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

> doesn't share lost of the performance penalties of Groovy

That's a bit of a myth these days. Groovy may even be more performant than Kotlin when used with static compilation.

Re: Java 12

#348

Post by unrealhoang »

antpls wrote: post #297
DaiPlusPlus wrote: post #234

Earlier quoted context omitted.

Trivial reference-counting can lead to memory leaks when you have an object graph that’s disjoint from an RC root object. Non-trivial reference counting starts to look like mark-and-sweep GC. And even then, when a ref count drops to zero, the runtime cost of destruction and deallocation of particular objects can be expensive. Stop-the-world GC is bad, but “make a blocking call because you can’t use async APIs in dest…

From my understanding of Rust, you will still pay the runtime cost of destruction and deallocation of objects with the object lifetime system ? It's like reference counting, but precomputed by the compiler. Please correct me if I'm wrong.

It’s like manual allocate/deallocate. Only that the compiler will insert free (or drop, in case of Rust) for your variables when it reaches end of scope.

Re: Java 12

#349

Post by lmm »

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.

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 course it's still possible to write in the XML/setter injection/afterPropertiesSet style, and always will be - that's backward compatibility for you - but it's very possible to migrate existing applications to a better style in place, which very few platforms manage).

> Same with maven/gradle, which turns what should be a developer-focussed build system into an enterprise XML mess.

Maven is pretty close to the perfect build system, it's just taken a while for knowledge and practices to catch up with it. All the stuff people love and praise Cargo for, Maven has been doing for 15+ years.

Re: Java 12

#350

Post by swish_bob »

krakatau1 wrote: post #339
james_s_tayler wrote: post #282

Earlier quoted context omitted.

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

because every Maven project is more or less same while Gradle projects vary drastically...I don't know how anyone can tolerate Gradle and performance benefit is not that great...

The performance benefit is huge.

I understand not wanting to learn another build tool, but I have no regrets where I've moved to gradle. It's so much faster on a project of any size it's stunning.

90% of maven projects don't do anything terribly complicated. Porting them to gradle leaves them uncomplicated and unexciting. I just wish there was a standard release mechanism. Poor as mavene-release is, at least everybody uses it and understands it.

Post reply on HN