I am a software engineer at Google on the Android project and the creator of the Java testing framework TestNG. When I'm not updating this weblog with various software-related posts or speaking at conferences, I am busy snowboarding, playing squash, tennis, golf or volleyball or scuba diving. Cedric is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

Next Generation Java is Not Very Different From Today's Java

08.12.2009
| 6244 views |
  • submit to reddit

In a recent post, Stephan Schmidt makes several suggestions in order to write "Next Generation Java". Unfortunately, I disagree with most of them... Let's take them in turn:

final everywhere
This is guaranteed to make your code littered with final keywords and therefore, impair readability significantly (same problem as Python's self pollution). And it really doesn't buy you that much, I can't even remember last time I was bitten by a bug involving the reassignment of a variable to a different value within a code block. For what it's worth, final on non fields is banned from Google's style guide (except where it's unavoidable, such as when you need to pass variables to inner classes).

No Setters
It would be nice, but it's just not realistic. Sometimes, you really don't want to put that many parameters in a constructor (and the Builder pattern doesn't solve this problem either). Besides, it's convenient to be able to mutate object if you want to use pools. As for not using accessors overall, Stephan is not the first one to argue that they should be removed from OO programming overall, but this claim is easily debunked.

No loops
Java is not very well suited to a functional style, so I think the first example is more readable than the second one that uses Predicates. I'm guessing most Java programmers would agree, even those that are comfortable with comprehensions and closures and especially those that aren't.

Use one liners
Depends. Sometimes, breaking down the expression and introducing variables clarifies the intent of the code and it also makes it easier to use break points.

Use objects with interfaces
A good advice overall, but don't go overboard. I have argued something similar in the past under the name Quantum Software Design but introducing too many interfaces can result in an explosion of little classes that cloud the intent of your high level classes.

Erlang concurrency
Again, it's dangerous to use a programming style that Java was not designed for. java.util.concurrent is a treasure trove of very useful constructs and I'd rather see a set of well architected Java abstractions built on top of it than an emulation of Erlang's actor architecture.

Fluent interfaces
Now that's an interesting recommendation since it contradicts directly Stephan's suggestion of not using setters, because make no mistakes: fluent interfaces are setters in disguise. So, Stephan, which one is it? :-)

Use public fields
No. Just, no. You will never regret adding accessors to your classes if you need the data, but I can promise you that you will rue the day where you decided to be lazy and to make a field public.

From http://beust.com

Published at DZone with permission of Cedric Beust, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Bruno Vernay replied on Wed, 2009/08/12 - 2:52am

That is exactly my experience. I have been very tempted to use this "new style", something more "functional" and with less boring code: getters and setters.

I started writing the classes with public final fields and no accessors. But then it seemed too risky. You never know what will happen and who will maintain the project. They might not be fan of "new style".

Same for the final keyword, I keep marking field final for the coherence, but I won't do it again in another project for the reason described.

At the language level, I don't think that the new Java will be Java. What is more tempting is to use DSL, like JetBrains MPS or oAW Xtext.  You write a clean code and it generates the boring, but still readable, Java code.

I feel the need to raise the abstraction level, but I think it will be above Java, like some still needs to write assembly code sometime. 

I hope that Oracle/Sun will give a strong lead into something new. Otherwise the adoption will be very slow if one has to choose bewteen Scala, MPS, Xtext and 10 others higher level alternatives.

Alex(JAlexoid) ... replied on Wed, 2009/08/12 - 7:23am

Use public fields
No. Just, no. You will never regret adding accessors to your classes if you need the data, but I can promise you that you will rue the day where you decided to be lazy and to make a field public.

 I would like to heara coule of stories abou how public fields ruined something big. I do have at least 4 stores where an idiot programmer forgot to add "this." in the setter and we had compiler silent with horrible data loss consequences.

Oh, CedrI believe that one of your colleagues will disagree with you, see Cris Pruett here on Real-TimeGames on Android

I started writing the classes with public final fields and no accessors. But then it seemed too risky. You never know what will happen and who will maintain the project. They might not be fan of "new style".

 As I mentioned above, please don't threaten peole with theoretical bogeyman and  just tell us a strory where public final fields became unsafe, without actual hacking(as shown in one of Java Puzzlers). Because in that case we should ban all "publis staitc final" type constants.

 

Sorry, I just hate when people start talking about "Might be, in theory, unsafe", because that is how we got EJB 2.1 Entity beans(Remember that abomination?).

Tasos Zervos replied on Wed, 2009/08/12 - 7:31am

Fluent interfaces can be setters in disguise. Stephan's example looks to be such.

When done properly they are not though...

Using a builder pattern they create nicely immutable objects. :-)

Check this with Josh Bloch. (I assume he is still around.)

 

Tasos

 

(Alternatively check Effective Java 2nd Edition, Item 2)

Erik Post replied on Wed, 2009/08/12 - 9:35am

Hi Cedric,

Now that's an interesting recommendation since it contradicts directly Stephan's suggestion of not using setters, because make no mistakes: fluent interfaces are setters in disguise. So, Stephan, which one is it? :-) 

JavaBeans compliant setters must return void, which means you can't use them to give you a fluent interface. So in that case it's really not a contradiction, unfortunately.

Tim O'farrell replied on Wed, 2009/08/12 - 10:40am

Fluent interfaces do not have to be setters and can be really useful in a given niche - take jquery for example.

Filipe Cardoso replied on Wed, 2009/08/12 - 11:15am

I can easily imagine problems that could easily be fixed if a setter was used instead of a public field. Validation for once. So most of the times I would go to a getter/setter approach. But I agree the getter/setter is a pain. Java language should allow property fields. Not the ones used in .NET but something that could excuse us from having to write the usual getter/setter methods that simply get and set the field.

Sean Anderson replied on Wed, 2009/08/12 - 2:31pm

It really is true, programmers are lazy. I shyed away from reading Java and development blogs because of the endless complaining about trivial things like generics in Java for instance.

I come back and now its endless arguing over get and set methods. OMG!

Just code the damn get/set and get on with your life. They are nessesary; maybe this is a sign of our decline as a society? For the love of Peat all we have to do is write a batch of code and the computer then does our work for us. Next we'll be talking about not wanting to code at all! I'd love to see that discussion.

Maybe we could build a language/interface that would no longer need actual developers? Electrodes could be hooked to the users head and by sensing the variation in magnetic frequency the system would construct the necessary software to fill their needs. Then we could all stop complaining and retire to a trailer park and eat cat food (or Hungry Man dinners)!!

Has it always been this way?

Liam Knox replied on Wed, 2009/08/12 - 7:30pm

I find the Google final code convention ironic. You have the cheif Java architect writting Effective Java and encouraging strong encapsulation and immutability, yet their code convention would increase the chances of immutability being broken by some adding a sloppy set.

Are you sure they have such a rule ?

Aljoscha Rittner replied on Thu, 2009/08/13 - 2:43am in response to: Filipe Cardoso

I like the JavaFX way. JavaFX use public fields and no properties. But bindings. No getter and no setter. For validation add a binding to a field and reject wrong values. So it's easy to set values w/o loosing the control. Never the question: Should I use a property, a private field, a public field or get/set-methods.

Add a field: first protected

Later, open the field to public-read

If you need more: public

If you need validation or event handling: bind the field

But never change the caller: So, you get a stable API.

 

Anyway, if NG Java adds final/const fields, removes loops and setter: We have a functional language. At this time, please use another name (not Java) ;-)

br, josh.

Jess Holle replied on Thu, 2009/08/13 - 6:46am in response to: Sean Anderson

Great post Sean!

This whole tirade about getters and setters does seem way overdone -- especially when the IDE will write them for you and collapse them out of the way for you in the editor.

Sure an "object->property" notation which seamlessly works whether property is a public field or instead has a public accessor would be nice, but really how hard is it to just add the setter immediately?

By the way actually being able to use "object.property" here is a complete non-starter as it would either break *lots* of code or have completely different meanings inside the package or class in question than outside it.  The "." notation has always and must continue to mean direct access to the field whenever the field is accessible to direct access.  A new notation is therefore required to mean "use the appropriate public/external access to the property".  There seems to be an unwillingness on the part of those who dislike having to write getters/setters to acknowledge this -- as they do not want to have to type an extra character or do anything different than in EL or such.  At which point, I'd just have to say go back to getters/setters and forget such property notations if you can't grok that "object.property" notation cannot be added to Java at this point due to the complete mess it would make of things.

Tom Wheeler replied on Fri, 2009/08/14 - 12:39pm

I'd find Google's style guide on Java enlightening to read.  I've searched for it (using Google, no less) but cannot seem to find a copy.  Is it available outside the company?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.