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

141–150 of 228 posts

Re: Java 9 features announced

#141

Post by Guvante »

dragonwriter wrote: post #136
adevine wrote: post #129

Earlier quoted context omitted.

I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients ne…

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

Re: Java 9 features announced

#142

Post by Alupis »

Afforess wrote: post #139
Alupis wrote: post #116

Earlier quoted context omitted.

Anyone know what the "sjavac" is about? The link just talks about improving it so it can become the new default... but what is better about it? Is it just the new javac?(why not just in-place upgrade javac then?) (link provides no real details: http://openjdk.java.net/jeps/199 )

I was curious myself. I dug up the original proposal to create sjavac, which is here: http://openjdk.java.net/jeps/139

Interesting -- finally bringing multiple-core/process compiling to javac. Although, I must admit, I have yet to work on a project where compile times were a major issue. I guess I'm just in the habit of typing "ant release" and getting some coffee ;)

Re: Java 9 features announced

#143

Post by andor »

grizzles wrote: post #99

My Wishlist: 1. Fix Daemonization! Publish an official blessed and supported way of daemonizing processes. Yeah sure, you can use Apache commons-daemon and others of it's ilk. And it will work. But it will feel hacked together (at least it does to me). 2. Fix Dependency hell! Publish a blessed / supported / standard of supporting / managing different classloaders. Java has this great mostly unused mechanism (classloa…

Fix Daemonization

This is fixed by process supervision software such as systemd -- no need to implement it yourself. Just leave your application running in the foreground.

http://0pointer.de/public/systemd-man/daemon.html

Re: Java 9 features announced

#144

Post by LoneWolf »

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.

Why not just declaring the fields public and access them directly? Is there anything I am missing?

Re: Java 9 features announced

#145

Post by ollysb »

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…

This seems like a perfect example of a pattern applied in the wrong way. The builder pattern is supposed to be used to construct new instances (in other languages named parameters make it pretty redundant). I could perhaps understand allowing people to batch up changes but when you're forced to switch to a builder and back again to make a change to one field you've definitely got a poor design. The example seems particularly egregious because you're also forced to walk the domain where really you should just be able to do:

    user.addFavourite(album);

Re: Java 9 features announced

#146

Post by andor »

ZoFreX wrote: post #16
curiousCoffee wrote: post #10

Earlier quoted context omitted.

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

notch is rapidly developing a game in Eclipse

He's modifying the Swing object tree from the main thread! Don't do that, Swing isn't thread safe ;-)

https://www.youtube.com/watch?v=rhN35bGvM8c#t=1454

http://docs.oracle.com/javase/7/docs/api/javax/swing/package...

Re: Java 9 features announced

#147

Post by cgh »

grizzles wrote: post #99

My Wishlist: 1. Fix Daemonization! Publish an official blessed and supported way of daemonizing processes. Yeah sure, you can use Apache commons-daemon and others of it's ilk. And it will work. But it will feel hacked together (at least it does to me). 2. Fix Dependency hell! Publish a blessed / supported / standard of supporting / managing different classloaders. Java has this great mostly unused mechanism (classloa…

For 2, what's required is a module system. OSGi provides such a mechanism but it's not "official". Each OSGi bundle has its own classloader.

Java 8 was supposed to provide modules but they were scrapped so in the meantime, OSGi is the only option.

Re: Java 9 features announced

#148

Post by kasey_junk »

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…

I agree with your design idea, but it fundamentally misses the point of getter auto-properties and that is binary compatibility in the case of future change. That is, if you need to add some functionality to the accessing of the variable. Now I personally don't think this happens much, but it would be nice if the language allowed something that preserved binary compatibility across that change and was not verbose.

Re: Java 9 features announced

#149

Post by arjie »

stevebot wrote: post #137
arjie wrote: post #125

Earlier quoted context omitted.

Well, the answer depends on the function, the purpose. I suppose he's saying that you should encapsulate with the object. For example, you have an OrderLine object, you don't `o.setStatus(CANCELLED)`, you `o.cancel()` etc.

That examples makes sense, but what about Strings and other types? I'm not sure you can do the same thing for a User object with name, age etc. I'd love to not have getters/setters but I have yet to see a replacement for all get/set scenarios.

That's a Plain Old Data object and back in the day the Sun Java Coding Conventions recommended public instance variables for classes which "would have been a struct if Java supported it" or something like that.

I suppose it's all about behaviour. If the class is literally just a struct - a box for data, there's no functionality to describe. Choosing public instance variables vs. getter/setter is just a matter of choice at that point.

The latter let you check Preconditions, etc. but that means that you actually have some invariant you intend to preserve (date of birth of the user cannot be in the future, for instance, so your well-formed user has some characteristics). Any members that can take any value their type permits should, in my opinion, just be public. Logically if you perceive that you could have some invariant in the near future, you'd want to have getters/setters but there's no point overdoing it.

Re: Java 9 features announced

#150

Post by spopejoy »

rbanffy wrote: post #102
ryanobjc wrote: post #97

Earlier quoted context omitted.

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…

> It is addressed by better design. This! A lot of the horrible Java you see around is nothing but an artifact of mindlessly applying patterns to constructs that don't need them. > a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming. Which is quite unforgivable, considering Smalltalk has been around since the early 80's.

My problem is I don't think there's any agreement what Object Oriented Programming is and isn't, so it's pretty hard to "properly do it".

Let's see. OOP generally involves "objects", ie structs or records with visibility controls on fields, sporting "methods," ie functions with a magic/hidden this/self argument. This alone doesn't buy you much, and in fact is quite inflexible when compared to good old ADTs, so let's hope there's more to it.

OOP does not mean "all methods are defined within the class declaration/file" a la Java, plenty of OOPLs allow external method definition. So it doesn't mean "well in OOP I always know the behavior of my class" when you have friend functions etc.

OOP might mean "abstract classes" ie virtual methods. This leads us to inheritance, which is a) not confined to OOP and b) widely criticized. Remember that inheritance != polymorphism, c.f. Visual Basic for instance (at least VB5. Showing my age...). In practice, OOP usually invokes a great-chain-of-being-like hierarchy descending from Object, but again this is not universal.

OOP generally means "polymorphism", but the mechanisms vary widely. OOP's "Classic" inheritance-driven polymorphism is probably the worst way to do it, good for quick code-reuse and that's about it. "Interfaces"/pure virtual classes are a design pattern on top of abstract classes, better expressed as mixins or type-classes.

OOP generally implies strong typing but not always (python). OOP typing is quite clunky, especially in "noun-oriented" Java. You can make an argument that the rise of DI frameworks is in response to having impoverished type systems.

My semi-rant here is because people say things like "do it this way, it's good OOP" without there being any agreement about whether we're discussing polymorphism, inheritance, encapsulation, factoring, normalization, or design patterns that are largely a response to the confusion.

On the other hand we have folks like the clojure crowd bagging on OOP using similarly vague concepts like "OOP means stateful objects/side effects" ...

Post reply on HN