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

141–150 of 478 posts

Re: Java 12

#141

Post by Viliam1234 »

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; }

In Java, the concept of exceptions is incompatible with the concept of parametrized types.

During compilation, type parameters are erased. "T" becomes "Object"; "T extends Something" becomes "Something"; assignment becomes type conversion. But at the end it works correctly. If you try to make something that wouldn't survive the type parameter erasure -- such as having two methods with the same name, one of which accepts "List" and another accepts "List" as their input -- it will be a compile-time error, because you can't have two methods with the same name and the same parameter "List".

But imagine that you have a type "MyException" extending RuntimeException, and your code has "catch (MyException)". After compilation, this would become "catch (RuntimeException)", which is wrong, because it would also catch other RuntimeExceptions, and it is not supposed to. But if you make this construction a compile-time error, then... the whole thing becomes useless, because what's the point of having an exception type you cannot catch.

Re: Java 12

#142

Post by vbezhenar »

dragonwriter wrote: post #122
vbezhenar wrote: post #23

Earlier quoted context omitted.

If they are officially bad, remove them from the language. It's a backwards-compatible change. Currently we are in a weird situation, when standard library does not work well with each other. It's like making iPhone without USB-C cable and Macbook without USB-A port.

> It's like making iPhone without USB-C cable and Macbook without USB-B port. Was there ever a MacBook with USB-B?

Why not? https://apple-history.com/mb_late_09 for example.

Re: Java 12

#143

Post by boksiora »

_bxg1 wrote: post #33
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…

Java has evolved pretty far past its strict OOP roots. I haven't kept up with the last few versions, but it added lambda functions way back in Java 8, for example. There's definitely syntactic baggage holding it back in some ways, but it's added lots of features for more modern functional-programming styles (one mentioned in this release is expression-style switch statements). More importantly, the JVM ecosystem is m…

thank you for this comment. it brings a lot of light on the ecosystem

Re: Java 12

#145

Post by vbezhenar »

Viliam1234 wrote: post #141
vbezhenar wrote: post #20

Earlier quoted context omitted.

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; }

In Java, the concept of exceptions is incompatible with the concept of parametrized types. During compilation, type parameters are erased. "T" becomes "Object"; "T extends Something" becomes "Something"; assignment becomes type conversion. But at the end it works correctly. If you try to make something that wouldn't survive the type parameter erasure -- such as having two methods with the same name, one of which acce…

The entire concept of checked exceptions is compile-time, because there's no checked exceptions in JVM. I don't really understand your argument. I'm not suggesting to catch exception of generic type, it won't be possible indeed, but it's not required either. You just need to tell compiler to pass "throws" via generic type. You can declare your map function with generic throws and compiler will respect that.

Re: Java 12

#147

Post by spricket »

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 anything you can imagine. ~4 solid IDE's.

Java's OO is fine, and all the nightmare patterns died years ago. You only see them because Java has been around for so long. Modern frameworks like Vert.X or DropWizard are fairly nice to work with. Even Spring Boot isn't too bad.

But Spring is dated and not often used for new projects.

The JVM has extremely powerful built in monitoring API's that put any other language I know of to shame.

WebWorkers are trash compared to Java's nice threading model. It even supports CPU optimized Atomics.

There's nothing unusual about writing microservices in Java. V8/Node is just as "big" a virtual machine as the JVM except JS runs ~5x slower and takes 5x more ram.

You can also write Lamda in Java.

There's many valid critisicms of Java but yours are largely invalid

Re: Java 12

#148

Post by mehrdadn »

chrisseaton wrote: post #131
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…

It's not complicated - the claim is that the pause only needs to be long enough to scan and update the root set twice and perform a little book-keeping, provided that allocation is slower than collection. That's black and white. Either Shenandoah is working correctly or you need to reconfigure. How do you know if allocation is slower than collection? The logs tell you. This is the same as any performance requirement…

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 unconditional "summary" like that with a straight face. It's practically dishonest to present it as if the giant asterisk isn't there. And this has nothing to do with the quality of the GC... I'm sure they've done great work, and if they're proud of it they probably very well should be, but that doesn't give us (or them) an excuse to advertise it as doing something it admits it doesn't do.

[1] https://openjdk.java.net/jeps/189

Re: Java 12

#149

Post by chrisseaton »

mehrdadn wrote: post #148
chrisseaton wrote: post #131

Earlier quoted context omitted.

It's not complicated - the claim is that the pause only needs to be long enough to scan and update the root set twice and perform a little book-keeping, provided that allocation is slower than collection. That's black and white. Either Shenandoah is working correctly or you need to reconfigure. How do you know if allocation is slower than collection? The logs tell you. This is the same as any performance requirement…

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.

Re: Java 12

#150

Post by kickopotomus »

ilovecaching wrote: post #101
yazr wrote: post #70

Earlier quoted context omitted.

> Isn't Java still one of the default languages ? Yes. There is no need to engage the GP - let him rant about Go and JS. Java is still huge, for both legacy and new projects. For context - I started as a C/Kernel dev. I also spent 2 years with Java on mission critical backend code. Both have their uses.

> For context - I started as a C/Kernel dev. So you have a very limited view on what sane development looks like. I assume this is just name dropping. > I also spent 2 years with Java on mission critical backend code. I feel bad for the people that will have to keep that code running. Because my point is that there are now better choices.

Are you familiar with the term "Magpie Developer"[0]? Your claim of "better choices" is highly subjective. To me, every point that ellard brought up makes Java "better" than JS or Go.

[0]: https://blog.codinghorror.com/the-magpie-developer/

Post reply on HN