Java 12 • Hacker News Board

Re: Java 12

#151

Post by _bxg1 » Tue, Mar 19, 2019, 11:23 PM UTC

spricket wrote: post #129

_bxg1 wrote: post #27

Earlier quoted context omitted.

GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages for game development. This could open up the JVM for games, which could have some exciting implications.

This has already happened in a way. Unity uses a ton of C# for scripting. While C# is somewhat nicer to work with, this low pause GC makes java a compelling option for moving much more logic into the VM language

Yeah, I do wonder how Unity deals with the GC. Maybe there's an algorithm like this one, maybe the engine's core systems (physics and graphics) are written in native code.

C# as a language does tend to be nicer than Java, but its VM doesn't have as rich a family of languages.

Re: Java 12

#152

Post by mehrdadn » Tue, Mar 19, 2019, 11:24 PM UTC

the8472 wrote: post #140

mehrdadn wrote: post #108

Earlier quoted context omitted.

It is nonsense though. I'm frustrated to see the same lie repeated over and over again. When nobody buys the lie a new GC comes out that everyone claims this time is really , truly going to do the impossible. With a giant invisible "implicit" asterisk that basically says "except when it doesn't, then it's your fault". It's been happening for... over a decade now? I don't even remember. > Shenandoah implicitly relies…

> which merely shifts the blame for the pause from the GC onto the application? There is no shift here, this has always been how things work. GCs are not a magic wand that allow you to do anything with reckless disregard towards efficiency with zero drawbacks (neither do malloc/free). Improved GC algorithms strive to cover more and more real-world workloads. Sometimes they fall short. Sometimes the developer did inef…

Well that's exactly the point too. GC's aren't magic wands, and people just need to be honest about the inherent limitations of whatever they build or use. You can't claim X is independent of Y when it very clearly cannot be, no matter how much you want that to be the case. That's all I'm saying.

Re: Java 12

#153

Post by saagarjha » Tue, Mar 19, 2019, 11:25 PM UTC

ilovecaching wrote: post #126

hkolk wrote: post #112

Earlier quoted context omitted.

Our company (on the scale of running it's own private cloud) has switched over to OpenJDK. Oracle is a non-issue for us For people actually working with JVM and the languages on top of it, nobody really is worried about Oracle. The way the licensing is set up, they just don't have enough power to coerce people to use their version. It would kind of be like the SCO case if they came after it. I think they went after G…

As a believe in free and open source software, I think this is a very head in the sand approach. Any portion of Java, even if it's just a certification being open source is enough to run away from it when there are so many alternatives that are better languages and completely open source.

OpenJDK is GPLv2. I know of only a handful of other, popular languages with a license as copyleft as that.

Re: Java 12

#154

Post by saagarjha » Tue, Mar 19, 2019, 11:26 PM UTC

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…

> Just because you have a map and sort method and a hacked in lambda syntax doesn't make Java anything less than OO.

Maybe not fully functional programming, but something that's quite pleasant to work with to be sure.

Re: Java 12

#155

Post by _bxg1 » Tue, Mar 19, 2019, 11:27 PM UTC

ilovecaching wrote: post #97

_bxg1 wrote: post #27

Earlier quoted context omitted.

GC pauses have been one of the major barriers to using garbage collected (read: higher-level) languages for game development. This could open up the JVM for games, which could have some exciting implications.

Honestly, if you need real performance when writing a game, there's no reason not use the language that's most popular for your engine of choice. Mostly that's gong to be C++ with python scripting.

The GC doesn't just affect high-performance games. The problem is it doesn't just make things broadly slower; it introduces what can easily become a second-long pause a couple times a minute. Even if your game runs buttery smooth the rest of the time, that's pretty much unacceptable. There are measures to minimize it - object pooling, for example - but they remove most of the benefits of having a GC in the first place.

Re: Java 12

#156

Post by mehrdadn » Tue, Mar 19, 2019, 11:27 PM UTC

chrisseaton wrote: post #149

mehrdadn wrote: post #148

Earlier quoted context omitted.

I don't know what "work" of mine you're referring to (I never claimed to have a GC that can do the impossible either?), but what I'm taking issue with is the clearly bogus sentence from their summary [1], which was repeated at the top here: > 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. You can't just write an un…

If you know the claim is bogus then you must have done the work to prove that. Show that work to them and stop being so unpleasant to me.

I thought we already established this. It was the GC documentation itself [1] that admitted the summary was bogus. Specifically:

> Usual latency induced: >100 ms, but can be more, especially on a very occupied heap

[1] https://wiki.openjdk.java.net/display/shenandoah/Main#Main-F...

Re: Java 12

#157

Post by willtim » Tue, Mar 19, 2019, 11:28 PM UTC

coldtea wrote: post #69

ilovecaching wrote: post #64

Earlier quoted context omitted.

It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. It's actually a bad idea to try to retrofit a paradigm on top of an existing language. You should build tools that do one thing well, and if they no longer suit your style of programming, you should switch to a tool that is designed to fit your needs.…

> It seems to be a popular notion that adding constructs common in FP is somehow a modernization of C++ or Java. FP isn't a set of features, it's a style of programming. And historically, nobody cared for that style of programming in its pure form (where "nobody" is in the casual sense: a few FP-lovers, but not the 95% of working programmers). From 1960 to today it remains niche in its pure form, even the most popula…

> And since FP is a style, it can be followed quite effectively in almost any language.

It's not black and white. FP is more like a spectrum, with pure functional programming more towards the opposite end, just before total functional programming. Put another way, adding lambdas to Java does not make it like Haskell. Even Scala cannot effectively be used as Haskell substitute, as some in that community eventually realised.

It remains to be see how much of FPs benefits (composition, abstraction, reasoning) can be fully realised in languages with rampant side-effects and mutation.

Re: Java 12

#158

Post by twic » Tue, Mar 19, 2019, 11:29 PM UTC

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…

We should print out copies of this comment, and laminate them, and give them to anyone who thinks that comments on HN are good, as an educational resource.

Re: Java 12

#159

Post by vbezhenar » Tue, Mar 19, 2019, 11:31 PM UTC

vbezhenar wrote: post #20

crooked-v wrote: post #4

Still nothing to handle checked exceptions in streams properly... sigh.

I wonder why they didn't use generic exception type in their java.util.function classes. That would propagate checked exceptions statically. Something like @FunctionalInterface interface Function { R apply(T t) throws E; }

On further thought I understood that streams usually are lazy and real exception would be thrown not at map, but later (probably in collect or similar method). So it would require to propagate that E generic parameter to almost every function (and Stream type signature). Also it won't work well with multiple checked exceptions. So yeah, not that easy.

Re: Java 12

#160

Post by RussianCow » Tue, Mar 19, 2019, 11:31 PM UTC

spricket wrote: post #125

stefan_ wrote: 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

Frame drops that happen more than once every several seconds are definitely noticeable (and, as a sibling comment pointed out, especially so in VR). Plus, throwing away more than half your frame budget just because of GC seems unreasonable. And this isn't even considering monitors with high refresh rates, which are slowly getting more and more popular.