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

381–390 of 478 posts

Re: Java 12

#381

Post by jacques_chester »

ilovecaching wrote: post #106
jm4 wrote: post #94

Earlier quoted context omitted.

Do you know anything about Java? I'm not trying to be insulting. Java has its problems, but your points are so far off the mark. Applets haven't been a thing for 20 years and I'm not sure they were a thing then either. Do you know people make web apps in Java and there's a ton of quality open source libraries out there?

I developed Java (Swing, Spring, JavaFX), managed tomcat deployments, good stuff. I think my question is, do most Java developers really know what goes outside of their window? Every language has a good story for web apps these days. The web is ubiquitous. You can write in Phoenix, Cowboy, Rails, Sinatra, Express, "net/http", Django, Laravel, Flask, Rocket... Java is literally middle of the pack at best. So that's no…

> Java is literally middle of the pack at best

A warm JVM is faster than a greased millenium falcon.

Re: Java 12

#382

Post by jacques_chester »

ilovecaching wrote: post #57
wpdev_63 wrote: post #39

Earlier quoted context omitted.

There's definitely alot of 'enterprisey' java code out there but that has more to do with the way people code than the language is now. Functional programming(.sort, .map etc) introduced in Java 8 allows more concise code and less boilerplate. Even with Rust, Go, and .Net core out there it's really hard to beat Java's battletested libraries/frameworks and excellent tooling. Java is still very relevent today and will…

Battle tested and tooling really aren't compelling arguments anymore, Java is very middle of the pack in both regards. Go is running as the basis of the next generation infrastructure in Kubernetes, Prometheus, Docker, Terraform... Elixir has revived Erlang, which now has great tooling in mix and is well known for being highly reliable. Go, Javascript, and Rust all have real package managers (even Go with mod) that a…

> Go is running as the basis of the next generation infrastructure in Kubernetes

And it requires acres and acres of generated code, a custom runtime dynamic type system, whacky module names for compatibility instead of a reliable build system like maven, to make the thing work at all. Kubernets is a multi-megaSLOC advertisement for the virtues of Java as an ergonomic experience.

If it had remained in Java it could be incrementally ported to Kotlin. God, what I wouldn't give for that.

Re: Java 12

#383

Post by coldtea »

pjmlp wrote: post #315
euyyn wrote: post #295

Earlier quoted context omitted.

Kotlin though. Everything you said, but a joy to write instead of a chore.

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.

Re: Java 12

#384

Post by [deleted] »

jaabe wrote: post #298
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.

If you develop, not if you maintain. This is a major reason we stay away from JS frameworks after burning the hands on implementing an AngularJS that was obsolete a year later. That and a few page reloads never killed anyone.

[deleted]

Re: Java 12

#385

Post by coldtea »

pjmlp wrote: post #351
ptx wrote: post #338

Earlier quoted context omitted.

Kotlin is different because of the focus on tooling, which is the advantage Java still had over all the dynamically typed JVM languages. Also, Kotlin/Native is in beta now and could target Fuchsia (compiling AOT to native code using LLVM).

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 worry about versus what Go, Rust, C++, Dart, D, Nim offer in terms of performance, libraries and in some cases tooling.

IMHO, Rust will always be kind of niche as hard to tackle, Dart we'll see, D never went anywhere, and Nim will remain niche, it's a little too idiosyncratic to catch on.

Kotlin is already more popular than all of the above except perhaps Go.

>Fuchsia is being written in Go, Rust, C++ and Dart, with the team now hiring for node.js support.

Fuchsia is still vaporware or at least irrelevant. It's not even in the market yet. And the fact that it's written in 4 (and looking for 5th) languages doesn't really bring much confidence.

Re: Java 12

#386

Post by wink »

I wonder if they'll fix the performance again. I'm mostly peripheral to clojure-land and 8 still seems to be the best choice.

Re: Java 12

#387

Post by jacques_chester »

MarkMc wrote: post #279
sbov wrote: post #269

Earlier quoted context omitted.

What code are you writing that Tomcat runs? Are you coding against the servlet spec? Or are you using something like dropwizard? Tomcat is a servlet container that implements various Java EE specifications, such as the servlet spec, jsp spec, etc. Spring encompasses many different libraries. The most widely used is probably Spring MVC, which builds on top of the servlet spec to make building web applications easier.…

Thanks - that's a good overview :) Most of my apps just code against the servlet spec with a JDBC connection to a MYSQL database, sometimes with JSP. Perhaps because most of my business logic lives on the client I've usually found that plain servlets + plain JDBC calls were sufficient Although I've found it pretty straightforward to configure servlets in Tomcat I can see that Spring MVC makes it a little easier. Mayb…

One nice thing about Spring Boot is that you can mix and match. You can assemble stuff very quickly using the starters, or you can use your own stuff. Pretty much any level of abstraction is supported -- Spring Data spans the range from "thin convenience wrapper over JDBC" (JDBCTemplate) to "completely autogenerated RESTful endpoints based on JPA models" (Spring Data REST). In web land you can use raw servlets up to fully-dressed domain objects. Whatever you want, Spring can either fill in the gap or politely yield the floor.

Not forgetting that dependency injection -- the original core feature -- is just the bee's knees.

I work for Pivotal, but not on Spring. But I've definitely grown to appreciate it more and more over the years. I deeply miss it when mucking about in Golang.

Re: Java 12

#388

Post by pjmlp »

zmmmmm wrote: post #105
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…

It's fascinating reading a post like this because I feel exactly the same from the opposite perspective. I feel bad for people trying to write in other languages and manually re-inventing dozens of features the JVM ecosystem just gives you for free. In many ways, the whole container-push has been essentially people trying to achieve what the JVM already gave you (isolation, cross platform, etc etc). I still don't see…

Yep, WAR and EAR files with J2EE servers.

When I stopped caring about POSIX.

Re: Java 12

#389

Post by tannhaeuser »

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…

The basics of maven might be sound (though it could make it easier to work with local dependencies) and npm et al have basically copied it. Where maven dropped the ball is the myriad of maven plugin magic, maven's implicit lifecyle, and a pom.xml's Turing pits, etc. I've developed Java apps since almost the beginning, and am as much of a markup geek as could be, but still hate maven with a passion, and often times do not understand what tf it wants from me. I just don't have the patience with wading through crap that 2003ish Java nerds thought would be a good idea. And increasingly, as Java libs get EOLd, this will be a major problem for monolithic Java apps with tens of submodules. I don't think you can expect younger devs to keep maintaining daddy-o's web framework crap and cleanup the mess left by Java heads.

However, I don't want to sound too negative. I can see a perspective for the JVM (Graal/Truffle) as a polyglot runtime where most of the ancient Java stuff is hidden from you, and you're using JavaScript or other non-JVM-only language as a migration strategy to get rid of Java alltogether in the distant future.

Re: Java 12

#390

Post by steveklabnik »

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.

The way the "it's like reference counting" mental model goes wrong is that things don't live arbitrarily wrong. Reference counting is used to extend the life of things, Rust will not do that.

But yes, it's malloc and free.

Post reply on HN