Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JDK 8 Release Notes

oracle.com

Post reply on HN
Print view View original

81–90 of 314 posts

Re: JDK 8 Release Notes

#81

Post by brown9-2 »

michaelt wrote: post #42
jpitz wrote: post #7

Earlier quoted context omitted.

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.

If you aspire to make Java into the type of language we would arrive at if we redesigned Java from scratch today, it's not just a matter of adding good features but also removing bad ones. For example, you'd go directly to Joda-Time or JSR-310. Date and Calendar wouldn't be present at all. Whether Java should break compatibility to remove all the old cruft I'm not sure. The benefits of the cleaner design might not be…

Is there any major language out there that actively removes old/bad parts of it's standard library?

Re: JDK 8 Release Notes

#82

Post by mjt0229 »

mariusmg wrote: post #17
bane wrote: 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…

C# is a nice languae. Java...not so much. Properties, delegates, proper generics, LINQ and so on.

The real problem with C# is that it is still basically Windows-specific. Yes, Mono is out there, but have you actually tried to build a Mono app without using Xamarin? Have you looked at what the Xamarin licenses cost? Once your project reaches a certain level of complexity, you have to pay them outrageous fees. And even with it, it still feels like you're operating something that could keel over at any second. The ecosystem there is just terrible, which is a shame because F# is such a great language.

The thing that makes Java so great as a platform is that there are so many totally reasonable tools that you can just download and use. Eclipse, IntelliJ (community version, which is still pretty good), the myriad of excellent alternative JVM languages, all freely available and cross platform.

Re: JDK 8 Release Notes

#83

Post by brown9-2 »

latchkey wrote: post #10
jpitz wrote: post #7

Earlier quoted context omitted.

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.

Agreed ...and jdk8 includes what was effectively joda-time (jsr-310) now. projectlombok.org also makes a lot of the language syntax ugliness quite bearable.

If you like lombok you might also like the Autovalue plugin from Google: https://docs.google.com/document/d/1THRUCIzIPRqFSHb67pHV8KMb...

Re: JDK 8 Release Notes

#84

Post by brown9-2 »

jrabone wrote: post #56
nicobn wrote: post #33

Earlier quoted context omitted.

I was going to reply with exactly the same thing, and I'd add slf4j.

Because God knows, Java needs another logging framework. Seriously does ANYONE get any additional value out of the morass of crappy logging systems out there over and above System.out.println? Log4J is PARTICULARLY brain-damaged, with its refrain of "ooh, someone put a log4j.xml in their JAR (one of hundreds), that beats your log4j.properties.". Or SL4Js amazing performance of "1.6 doesn't work with Scala because of…

logback is pretty great. I can't take anyone seriously that defers all logging to System.out.println - do you really want the inability to change logging levels between live, test, etc?

Re: JDK 8 Release Notes

#85

Post by suyash »

bane wrote: 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…

Java is the #1 language in the world. It's the best out there, period.

http://jaxenter.com/java-is-the-world-s-1-programming-langua...

Re: JDK 8 Release Notes

#86

Post by bradleyjg »

iSnow wrote: post #75
Pxtl wrote: post #45

Earlier quoted context omitted.

Breaking backwards compatibility isn't really an option, but if the compiler and IDE would discourage the use of legacy features that would be best. Just remove the legacy/ugly methods and packages from the autocomplete process, and warn with recommendations/flag as deprecated. You don't actually have to break anything.

Actually, every IDE warns you if you try to use a deprecated method. They show as strikethrough in your source too. There are things like http://docs.oracle.com/javase/7/docs/api/deprecated-list.htm... and IDE's know about this.

Problem is Sun^W Oracle hardly ever depreciates anything. There are 21 classes in that list (7 in java.*), out of a total of almost 4000 as of java 7.

Re: JDK 8 Release Notes

#87

Post by eropple »

suyash wrote: post #64
eropple wrote: post #32

Earlier quoted context omitted.

I've been using JDK8 for a while, but no Nashorn on Android keeps me on Rhino. Which is unfortunate. Rhino's a pain.

Android doesn't use Java 8, I believe it's mostly still on Java 6.

Yes, I'm aware, thank you. There are efforts to port Nashorn back to Android.

Re: JDK 8 Release Notes

#88

Post by cgh »

bradleyjg wrote: post #38
jpitz wrote: post #7

Earlier quoted context omitted.

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.

Filing in the holes is nice, but without actually making it a design choice java embodies TMTOWTDI more than perl ever did. For many common tasks there are 5 or 6 different standard library calls that seem to do the same thing, but 4 of them are to be avoided at all cost, but there's no depreciation tag and the official javadocs don't contain any pointers to the newer classes.

Can you give some examples of standard library calls that are to be avoided at all costs but aren't @deprecated? Curious to know if I'm guilty of using them.

Re: JDK 8 Release Notes

#89

Post by pohl »

fosk wrote: post #74
mongol wrote: post #51

Earlier quoted context omitted.

Do you have more info on the cleanup in Java 9? Will they remove some deprecated methods then?

Methods are marked as deprecated when they're planned to be removed in the next version.

That's the story that gets told, but how often have they actually removed something after deprecating it? Does anybody have a single concrete example of a method that actually went away?

http://stackoverflow.com/questions/18063599/has-ever-anythin...

Re: JDK 8 Release Notes

#90

Post by eropple »

mbell wrote: post #35
eropple wrote: post #30

Earlier quoted context omitted.

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.)

> And it sacrifices type safety Groovy is optionally typed, you can have as much safety as you wish. > and performance to do so If you use static types, you can use @CompileStatic to get most of the performance back.

Optional typing adds a ton of sand to the gears when you actually are writing code. @CompileStatic requires you to spend entirely too long thinking about what's actually legal to annotate and generally sucks rocks to read and write.

So, okay, you're technically correct, which is every nerd's favorite kind of correct, but writing it that way sucks. Groovy isn't a bad scripting language (or wouldn't be if discobot ever got done), but it's unserious as a Java competitor where Java is good.

Post reply on HN