Live data from Hacker News

Java 9 features announced

jaxenter.com

11–20 of 228 posts

Re: Java 9 features announced

#13
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

Kotlin is pretty nice for that. Also, project lombok is nice for Java code generation. I wish it became more "standard"

Re: Java 9 features announced

#14
post #9

a new json api to be released 2016. Hopefully by that time json is still relevant. I know most likely it will but at the pace of change that tech has, im not betting. is there any contender to json at the moment?

We're talking Java here. Java is used by enterprises all over the world for mission-critical code. I have clients who are just now making the move to Java 7; so of course JSON will continue to be relevant for the next 10 years or more. It may fall out of favor among the Julia/Erlang/Scala crowd, but JSON is here to stay for enterprises.

As far as contenders to JSON, I can't really think of any besides XML. The biggest benefit to JSON is its simplicity; which becomes a huge drawback in a strongly typed language like Java.

Re: Java 9 features announced

#16
post #5

I'm deeply missing hot swapping. I believed it could be included in java 9 but i think we have to wait...

What is hot swapping?

Replacing code while it's running. Currently this is possible but quite limited in the official JDK, you can only replace the contents of method bodies.

Edit: Demo of it in action here, notch is rapidly developing a game in Eclipse by changing the code while it's running: https://www.youtube.com/watch?v=rhN35bGvM8c

Re: Java 9 features announced

#17
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

+1

It is pretty astonishing they haven't done something about that. It doesn't seem like it should be a very hard language feature.

Re: Java 9 features announced

#20
post #2

The lack of an official JSON API has been a huge sore point for quite some time and has spawned dozens of libraries re-implementing the same thing over and over (GSON, Jackson, and even my own nanojson). I do hope that we avoid the DocumentBuilderFactory mistakes of XML and just end up with One True JSON implementation this time.

Are you sure that's true? As you say, look at the "standard" API for XML parsing: a complete disaster. Dates, similar. Logging was slightly less disastrous because they took so much from Log4j, but they still made it unwieldy enough that the log4j guys ended up writing an API on top of that which everyone uses. Now, props where props are due: Sun crushed the collections APIs compared to other languages at the time. A…

I'll counter that with saying that j.u.l is not actually that bad, IMO, although I might be the only one in the world that thinks that. I always just choose j.u.l in my projects because it works well-enough. I just shim anything with slf4j if it speaks log4j or commons-logging (shudder).

Perhaps Sun should have just adopted slf4j and a simple console-logging stub, but I don't think j.u.l is really any worse than the alternatives -- only a different implementation.

Now date APIs: those do suck, but I think the new Date JSR will finally get things to a place where we can use Java Dates rather than Joda.

Post reply on HN