Live data from Hacker News

Java 12

jdk.java.net

271–280 of 478 posts

Re: Java 12

#271
post #168

Earlier quoted context omitted.

All of those points are also true for C#, which imho fixes a lot of Java's problems and is a much nicer language. With .Net Core maturing you even get the "runs everywhere" factor (at least everywhere you care about, i.e. Win+Linux+Mac), and Microsoft is a much better vendor than Oracle.

I gotta ask what in particular "problems" C# solves over Java, and I'm not talking about J2SE 1.4. Having dipped into C#, it feels like the designers resented OOP and reusable code. C# is not the new kid on the block and is almost 20 years old now.

> it feels like the designers resented OOP and reusable code

Can you give some examples, that wouldn't be equally applicable to Java?

Re: Java 12

#272
post #75
post #2

I wish they did not decouple JavaFX...

Why is that? Decoupling benefits JavaFX so it can have release cycles on their own pace.

Decoupling might have benefitted JavaFX, but it did not benefit me who develops professional desktop applications for a living, and it did not benefit my users.

If they wanted to decouple, they first should have created a cross-platform jpackager-like tool that generates native executables for major platforms.

I remember JavaFX was launched with great fanfare as a modern replacement, which it certainly might have been - a modern, efficient platform. I am afraid it will slowly decay and dissolve into oblivion to be replaced by gigabyte-size electron apps.

Re: Java 12

#274

Earlier quoted context omitted.

If you're really that much of a language snob then you should checkout kotlin. It has seamless integration with Java and has the _best_ ergonomics I've encountered language wise. Go can't even get it's packaging story straight and once again doesn't have generics which makes 'functional' programming a no Go;)

Generics have nothing to do with functional programming. I actually really like Clojure (really I just love Lisp). Go also has modules now.

Pervasive use of HOFs is kinda difficult without generics or some equivalent.

Re: Java 12

#275

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…

"One day Java will be like Cobol." I heard that one two decades ago about Java.

Two decades ago, Java was 3 years old.

It's still true, though, but it's a compliment. Most languages have no hope of ever becoming the next COBOL. For Java, it is practically a certainty, even if Oracle were to pull the plug on it this very moment. It's too big and too important to die.

Re: Java 12

#276
post #84

Earlier quoted context omitted.

Their lower end target is 10 ms. In a game, 16 ms is your entire time budget.

10 ms isn't all that much. When games load in assets they'll do various things like malloc huge chunks and you lose a few frames. If GC only causes occasional (maybe every 2 minutes) loss of a frame or two it should be no problem. If you watch benchmark FPS traces that count every frame delay you'll see that occasional stutters happen in basically every game. Loss of a single frame just isn't noticeable

Quake, back in the late 90s, would preload assets for all entities in a level at level load time explicitly to avoid stutter when the entity finally shows up and needs to make a noise or whatever.

And some games much later didn't. I recall needing to fire off a shot on each new gun I picked up in Far Cry to be sure I wouldn't get a stutter later at a more critical moment.

Re: Java 12

#277

Earlier quoted context omitted.

My limited understanding is that high end Unity devs code their stuff not to make garbage. Unity has a very nice system for profiling that sort of thing. Also, CLR has F#, which I like much better than Scala (and, no type erasure in CLR), Clojure which is ... just like Clojure on JVM, and C#, which as a Java dev since 1.1 I have come to prefer as a language even as I remain JVM ecosystem preferring on the server side…

Is Clojure on CLR actively maintained?

Yes, it's one of the officially supported platforms (albeit the least used one).

Re: Java 12

#278
post #250

Earlier quoted context omitted.

>GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages There is such a thing as reference counting :)

What makes you think reference counting leads to shorter pauses than tracing? While it is absolutely true that sophisticated implementations of garbage collection via ref counting can exhibit similar performance to sophisticated tracing algorithms[1], most implementations of ref counting aren't nearly as sophisticated as modern implementations of tracing, and tend to be worse. [1]: https://www.cs.virginia.edu/~cs415/…

Not necessarily shorter, but predictable pauses.

Re: Java 12

#279
post #269
post #194

Earlier quoted context omitted.

I know Spring and Spring boot are very popular, but I don't understand why. The Spring Boot home page says, "Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run"." What does that mean? What does Spring Boot give me that Tomcat doesn't?

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. Maybe the introduction of a framework 'Model' is also an advantage - I'll investigate further.

Regarding Spring security - would I use this package if I was implementing a "Login with Email/Password or Facebook or Google" feature to a website?

Re: Java 12

#280
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…

Interesting that they explicitly exclude time to safe point from that improvement. In my experience that is usually most expensive part of a stw pause.
Post reply on HN