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

Java 9 features announced

jaxenter.com

Post reply on HN
Print view View original

161–170 of 228 posts

Re: Java 9 features announced

#161

Post by gutnor »

ryanobjc wrote: post #97
rufugee wrote: 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.

It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…

That works alright up until you need to integrate with third party libraries like JSF, Seam, Hibernate, Jaxb, Spring, EL, plenty of other stuff that requires a "javabean"

Sure, you can beat the big ones into working, and there is generally no shortage of libraries in Java. But at some point you are just wasting resource to work around other people code. Java has properties and some libraries use them.

Discussing if you should use them at all is offtopic, the real problem is that java has properties but instead of being a language/compiler supported feature, it is only defined as a "convention" with some half-assed support classes. Seeing how popular properties are, that either needs fixing or deprecation (starting with all the Oracle provided framework that use them)

Re: Java 9 features announced

#162

Post by Roboprog »

tieTYT wrote: post #115
einrealist wrote: post #84

Earlier quoted context omitted.

What is wrong with restarting your application? Edit: Real Hotswapping will requires profound changes to the memory model. It would introduce too much complexity. I rather restart my application than to suffer from a fragile and leaking platform.

It can take up to 5 minutes to restart my application.

So run multiple instances of the app, and put some kind of load balancer / proxy in front of the instances.

Unfortunately, this will require externalization of state data, but if you can't be down for 5 minutes, that's what you need to do.

You probably only need one large server running the instances, rather than a cluster. Java apps don't seem to do well -- longer GC pauses -- when they have over 2 GB of memory, anyway, so run multiple instances of "small" apps on a server with say 12 cores. A single server with a large pool of RAM shared between a large number of cores can do pretty amazing things with a collection of "small" programs on it (DB, web service apps, message queue server, web servers)

Of course, I'm assuming said server isn't Windows...

Re: Java 9 features announced

#163

Post by btgeekboy »

miralabs wrote: 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?

I'd much rather have this pace of innovation than trying to keep up with whatever the Ruby community decides to use this week.

Re: Java 9 features announced

#164

Post by nostrademons »

stevebot wrote: post #138
batbomb wrote: post #126

Earlier quoted context omitted.

We already have that, it's called the Builder pattern.

Up until recently, I've enjoyed the builder pattern. It becomes a pain in the ass though when your objects are deeply nested. For example, with protocol buffers you end up doing things like. AlbumCollection collection = user.getPreferences().getFavorites().getAlbums().toBuilder().addAlbum(album).build(); Favorites favorites = user.getPrefernces().getFavorties().toBuilder().setAlbumCollection(collection).build(); Pref…

If you used the generated builder methods provided by protobufs, would it really be that bad?

  user.getPreferencesBuilder()
      .getFavoritesBuilder()
      .getAlbumsBuilder().addAlbum(album).build()

Re: Java 9 features announced

#166

Post by azinman2 »

kasey_junk wrote: post #66
kclay wrote: post #40

Is it possible to have native JSON parsing with JNI bindings to make parsing faster, or will the overhead cancel out any boost in performance?

Why wouldn't you be able to write JSON parsing fast in Java natively? Even if you can't, it's precisely the kind of thing that would pay a large JNI penalty.

Boxing and unboxing characters is a big part of performance penalties, especially when dealing with Unicode.

Re: Java 9 features announced

#167

Post by azinman2 »

justwannareply wrote: post #135
miralabs wrote: 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?

YAML ( http://www.yaml.org ) comes to mind, though I think JSON is a much bigger improvement over XML than YAML is over JSON.

Yaml is more for humans to read than json is, and doesn't have native functions in any browser.

Re: Java 9 features announced

#168

Post by evacchi »

bollockitis wrote: post #73
rufugee wrote: 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.

It isn't perfect, but Lombok[1] helps with this. It uses annotations to automatically generate getters and setters. The downside, of course, it yet another dependency and more annotations. [1]: http://projectlombok.org/features/GetterSetter.html

You can setup your build process to "delombok" your sources, so that the dependency would only be compile-time (which is pretty neat). Also, Lombok has @Data http://projectlombok.org/features/Data.html

Re: Java 9 features announced

#169

Post by marvy »

Guvante wrote: post #141
dragonwriter wrote: post #136

Earlier quoted context omitted.

> Contrast Java with Ruby or C#. There, the clients don't need to know whether they're accessing a member var or calling a method to get/set a property, NOR SHOULD THEY. Others have noted that in many contexts in C# there is a difference, so clients do need to know. As far as Ruby, clients definitely need to know, its just that since public fields can't happen in Ruby, its always method-based access for the normal ca…

> Others have noted that in many contexts in C# there is a difference, so clients do need to know. Which is why C# added automatic properties. You get the expandability without breaking clients or having to read/write extra code. public int Foo { get; set; }

Last time I checked (long ago), properties in C# don't work as ref or out parameters. Since C# actually distinguishes between ref and out parameters, it would be pretty easy to extend the language such that properties work whenever fields work, but sadly no one but me seems to care.

Re: Java 9 features announced

#170

Post by thescrewdriver »

rufugee wrote: 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.

> Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address.

We ran out of patience and switched to Scala. Never been happier :)

Post reply on HN