Live data from Hacker News

JDK 8 Release Notes

oracle.com

21–30 of 314 posts

Re: JDK 8 Release Notes

#22
post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

The problem is not java the lang. It's the java developers. Looks like they moved on to do angular now.

I partly agree with this.

I'm a systems engineer, but I have to touch some Java code from time to time. I always have an hard time with the amount of indirection an average Java developer can reach. Luckily a few smart guys were hired recently and they have past experience in contributing to the JVM and their approach to the code is completely different and much, much more simple to understand, and since they came onboard the performance of critical parts of our main application increased dramatically with a few lines of code instead of the previous 400 or so.

Re: JDK 8 Release Notes

#23
post #9

Yay!! Java 8 is released!! My favorite parts: - invokedynamic : http://stackoverflow.com/questions/6638735/whats-invokedynam... - Project Nashorn : http://openjdk.java.net/projects/nashorn/ - lambda expressions : http://openjdk.java.net/projects/lambda/

InvokeDynamic came in with Java 7. I've got a large code base here that uses it extremely heavily and it's great, though you do need to do some careful tuning to really make it perform, and then retune when they change the implementation. :-)

Re: JDK 8 Release Notes

#24
post #7
post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

There are warts in the standard library to be sure, but many of them have already been filled in by third parties like Apache Commons, Google Guava, and Joda-time. I'm sure there are others I'm not thinking of.

Yeah, and I've already come across most of those. Integrating lots of that stuff into the standard libraries that Java ships with would be exactly what I'm thinking of...and jettisoning all the broken GUI frameworks and such. And cleaning up the disaster pile that is I/O. I mean, I think there's still stuff sitting around in javax.* from when I last touched Java 14 years ago. I thought that was supposed to be the experimental branch where things might change without warning? Let's clean that up.

I know most IDEs just ship with all that stuff included, but I've found it makes packaging up things to give to somebody else a little more complicated than I'd like...which would be resolved in the standard libraries.

Re: JDK 8 Release Notes

#25
post #9

Yay!! Java 8 is released!! My favorite parts: - invokedynamic : http://stackoverflow.com/questions/6638735/whats-invokedynam... - Project Nashorn : http://openjdk.java.net/projects/nashorn/ - lambda expressions : http://openjdk.java.net/projects/lambda/

As noted in your link, invoke dynamic isn't intended to be used for Java developers - it's intended for non-Java languages running on the JVM.

Re: JDK 8 Release Notes

#26
post #9

Yay!! Java 8 is released!! My favorite parts: - invokedynamic : http://stackoverflow.com/questions/6638735/whats-invokedynam... - Project Nashorn : http://openjdk.java.net/projects/nashorn/ - lambda expressions : http://openjdk.java.net/projects/lambda/

Nashorn is said to be high-performance, and I've looked around for benchmarks several times since it was announced, but I still can't find anything but this:

https://github.com/tadas-subonis/java-nashorn-performance-sa...

What gives? Wouldn't a real comparison to Rhino and V8 (at least) be interesting?

Edit: strike that. Found someone who ran Octane and SunSpider and compared it to V8 and Spidermonkey: http://wnameless.wordpress.com/2013/12/10/javascript-engine-...

Re: JDK 8 Release Notes

#27
post #6
post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

>If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that this is what groovy and kotlin attempt to do. groovy is backwards compatible with java as well, in most cases java code is valid groovy code.

I've always been reticent to learn these offshoot dialects of languages unless I really needed to. I'd much prefer it if they were treated as syntax experiments, and good ideas from them filtered back into the main language.

Re: JDK 8 Release Notes

#30
post #6
post #4

You know, I've been messing around with Java little lately. Nothing too fancy. It's actually not a bad language -- with a modern IDE it's actually pretty quick and breezy to work with. If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that. There's too much old 90's cruft hanging arou…

>If the standard library was cleaned up and the warts were all removed and filled in, even if it broke compatibility (call it Java X or the Latte language or something) I'd be okay with that this is what groovy and kotlin attempt to do. groovy is backwards compatible with java as well, in most cases java code is valid groovy code.

Groovy isn't attempting to fix Java, it's entirely different. (And it sacrifices type safety--even what of it you get with Java--and performance to do so.)
Post reply on HN