Next-gen Java Programming Style

http://codemonkeyism.com/generation-java-programming-style/

by fogus • 17 years ago

99 75 17 years ago

gdp11• 17 years ago

Really good advice. Whenever I encounter Java code that employs some or more of these techniques, I feel a little bit better about the world.

Retric5• 17 years ago

Are you joking? This advice is horrible.

He is advocating taking a verbose language and making it even more verbose and far less efficient. Think about what the final in "public final int x;" means in #8.

Many Java developers have fallen for the idea that everything is an interface to an interface. However, if you start by trying to get stuff done, you find a most scaffolding is pure waste.

gdp11• 17 years ago

He is advocating using a style more like modern functional programming languages such as ML, Haskell and F#.

The example in #8 is essentially recreating primitive tuple types present in the languages I just mentioned. Given that the overheads on such an object are small, and the garbage collector is good at dealing with short-lived objects, it makes sense to instantiate a new class when it is necessary to mutate it. Your optimiser will love you, and maintaining this style of code is considerably easier.

francoisdevlin2• 17 years ago

I think it's funny that this is right next to the interview with Rich Hickey :)

fogus3• 17 years ago

If you look at the source for Clojure you'll see many (if not all) of these techniques used throughout with an additional focus on static classes and methods.

francoisdevlin2• 17 years ago

I guess what I was getting at is that real next gen style uses the JVM, not Java.

Down with Java, long live the JVM

WilliamLP2• 17 years ago

> Do not use loops for list operations.

I can not get behind this in Java if the filter, fold, or map operation is simply a one-off. (It's another matter entirely though if the power of the functional approach is useful in the situation, say if a filter should be switched dynamically.) To do this for something static though, such as eliminating empty strings or adding an array, is just worse than useless.

This is as clear an example as any of programming against the language, not into it. The code is longer, it is slower, and _for a Java programmer_ it is much less clear. Java was explicitly designed not to be a language for showing off cute constructs for their own sake.

jimbokun5• 17 years ago

It could be worthwhile if this proposal were implemented:

http://docs.google.com/Doc.aspx?id=k73_1ggr36h

"Here is the same code rewritten using the proposed syntax:"

    List<String> ls = ... ;
    Collections.sort(ls,
        Comparator<String>(String s1, String s2){ return s1.length() - s2.length(); });

By making anonymous inner class declaration more concise, you get many of the benefits of closures, without changing Java semantics.

barrkel• 17 years ago

I agree, but unlike the other commenter, I think some equivalent of LINQ or concise (i.e. using type inference) syntax for lambdas is necessary to really make it work. And even then, for imperative operations that need to be applied to a subset of elements of a list, an imperative for-loop is still usually the best way to do it.

mynameishere• 17 years ago

I don't understand google's awful implementations. In my code by contrast, a map function looks like this:

  public double foo(double x)
  {
    return x*x;
  }

  list=Utility.map(this,"foo",list);

jimbokun5• 17 years ago

You need to do reflection, which probably has performance implications. You also cannot do closures, which you can simulate with anonymous inner classes.

Might be worth the trade off in your case, but maybe not for the cases Google has in mind.

brunomlopes• 17 years ago

Not only does that require reflection, it is very error prone and not refactor-friendly. Just change the type of the list, change the method, and it will blow up on runtime instead of compile time. In my opinion, that goes against the grain of Java (and c#, in a way) of having the compiler doing a lot of checking for you.

Google's approach, while more verbose, is a bit safer and more idiomatic.

bfung• 17 years ago

In addition to the other comments, the Utility class used in this example defeats the purpose of OO programming that Java is more in tune with. What's to stop the proliferation of these Util classes with static methods?

I believe the more Java way would be to extend the List interface to add a map method and implement a corresponding class. To make this less of a pain, extend from one of the JDK provided classes if possible... but yes, it's still a pain.

jimbokun5• 17 years ago

Another thought:

Why doesn't Java make it easier to refer to a method and call it dynamically?

For this example:

    List<Person> beerDrinkers = new ArrayList<Person>();
    for (Person p: persons) {
        if (p.getAge() > 16) {
	        beerDrinkers.add(p);
        }
    }

If we had a legalAge method defined on Person returning true for any person over 16, then it would be nice to write the equivalent of

    List<Person> beerDrinkers = filter(persons, legalAge);

which would call the legalAge method on each person and keep the ones returning true. Like most things with Java, you can do this, kind of, but it means getting the instance class, looking up the method for the method name and signature, then invoking on the instance, all of which makes it just not worth it. Objective C has the idea of selectors, which is an easy way to specify the message you want to send to an object, which probably comes from some similar concept in SmallTalk.

This is arguably a more object oriented solution to this general problem. For one, it better follows Demeter's Law, as you do not need to expose the getAge property.

scott_s2• 17 years ago

In C++, the way you would do this involves boost::men_fn (http://www.boost.org/doc/libs/1_39_0/libs/bind/mem_fn.html):

  list<Person> beerDrinkers = filter(persons, boost::mem_fn(&Person::legalAge));

Where filter looks something like:

  template <class Sequence, class Pred>
  Sequence filter(const Sequence& in, Pred p)
  {
    Sequence out;
    for (typename Sequence::const_iterator i = in.begin(); i != in.end(); ++i) {
      if (p(*i)) {
        out.insert(out.end(), *i);
      }
    }
    return out;
  }

We can even use this style if legalAge is something that takes a parameter, like ageCheck(age) using boost::bind (http://www.boost.org/doc/libs/1_39_0/libs/bind/bind.html):

  list<Person> beerDrinkers = filter(persons, boost::bind(&Person::ageCheck, 21, _1));

jsankey2• 17 years ago

I disagree. The fact that it is slower has no practical impact in the vast majority of cases, and is certainly not nearly as important as readability. So it comes down to which is clearer, and I find the functional style - even with the extra ceremony - more clearly conveys the code's intent. No messing around with the how, just show me the what. It's not about showing off, it's about abstraction of extremely common idioms.

Pointing this out as unclear for a "Java programmer" is a bit of a red herring I think. Anyone can learn what map/filter/reduce/etc mean in no time at all -- it seems a simple task compared to learning the project-specific abstractions of any codebase.

WilliamLP2• 17 years ago

> Pointing this out as unclear for a "Java programmer" is a bit of a red herring I think.

I think it's really not. There's a talk out there, I think by Gosling, about the direction of Java including why lambdas were rejected for Java 7. One reason was actually to prevent the sort of functional code that polarizes people in terms of whether it is seen as beautiful or opaque. (E.g. currying, Y combinators.)

Java provides the flexibility to use functional programming through anonymous inner classes, but at considerable pain to the author. The point people miss is that that pain is actually a conscious part of the language design.

Anyone can learn about map/filter/reduce, and every programmer needs to for the situations when they are crucial. But on the other hand, the problems with explicit looping are much overstated and I'll admit to emotionally siding on the issue with the creators of Java and Python.

I don't think you can ever fully get the "how" out of programming, nor should you try, nor is "what" implicitly superior all the time in all situations.

darkxanthos2• 17 years ago

The code is longer: Without having something like extension methods this might be the case. I'm a C# dev so I'll partially concede here due to ignorance. That predicate syntax really does suck... it'd be nice if you had lambdas but [shrugs]

The code is slower: It is slower but in my experience it is very rare that our performance bottle necks occur in these sections of code. We have actually profiled our code and changed from for loops in the legacy version to a redesigned version of the class using this more functional approach during refactoring and we can meet our performance needs just fine. More often than not the big performance improvements lie in disk i/o or more intelligent algorithms rather than just a general use of more functional idioms.

Much less clear _for a Java programmer_: Isn't that always the case until programmers start to learn other ways of doing things? If this was just one guy and not what appears to be a industry wide sea-change maybe I wouldn't argue. The functional paradigm however is being given a fair amount of attention and I don't think it's something you can classify as a niche concern.

"cute constructs for their own sake"- I believe the point of developers moving away from loops is that we are starting to realize that explicitly asking the compiler to loop through these items in this particular order is over-specification 99% of the time. Really we are just saying do this to each one of these. By shifting to a functional paradigm these types of tasks can be easily parallelized and abstracted to the point that you really care about.

_cbsz• 17 years ago

How much power is wasted worldwide by slow code that isn't the bottleneck? Surely, fast habits are better than slow habits, all else being equal.

tetha2• 17 years ago

Maybe it is just me, but at least to me, a loop and an if (and an accumulating list) is far, far, far simpler (and thus, clearer) than... creating a new anonymous subclass from a templated class with an overriden method and invoking some other method? (at least, I think that's what's going on, I am not sure. A bad sign). And this is not because I don't get filter and functional programming (coming from pythons listcomps, having used haskell and lisp)

Xixi2• 17 years ago

I have to admit that the 5th point (Use many, many objects with many interfaces) leaves me thinking...

On the one hand I understand where the author wants to go : by implementing many many interfaces you eventually sort of "emulate" duck-typing, while at the same time reinforcing type safety (specially when it comes to String).

On the other hand, it sounds like a good way to make something that was verbose to begin with even more verbose... but maybe I'm mistaking. I don't do much Java recently (some GWT/GXT sometimes), but I will probably give it a practical try...

fogus3• 17 years ago

Not necessarily verbose, but moreso a larger codebase. Besides -- all of these extra classes are invisible with D.I. anyway right? ;)

Xixi2• 17 years ago

You're right, it will grow the codebase more than making the code verbose. And the code will probably be more readable.

But have you actually used this in practice ? Is it tractable ?

I'm actually thinking of trying this on (a rather old version of) C#, since I'm writing quite lots of code for (an old version of) mono. If only I could use F# sigh

jrockway2• 17 years ago

The problem I see is the amount of code that has to be copy-pasted, due to Java's lack of traits. If you want to write code like this, do yourself a favor and write it in Scala instead.

sciolizer• 17 years ago

Java's lack of traits does indeed suck, and I would definitely prefer Scala over Java, but the only copy-pasting you need to do is of delegation methods. It's duplicate boilerplate, but it's not duplication of logic.

jimbokun5• 17 years ago

"Refactoring is easy, should you need it. If you do not control all the code and it’s usage, you might need to be more careful though."

Bloch's Effective Java is wonderful, but if it has a weakness, it might be that it assumes everyone is writing a library to be used by a lot of developers, many of who are outside your organization.

The example of public fields in data transfer objects is an example of this. Making the fields public is fine if this code is just for you and your team, because you can always refactor it to use accessors later if you need to. But if this code is in a library used by people outside your organization, introducing accessors later without breaking code will be almost impossible.

JulianMorrison2• 17 years ago

Public fields like that announce that the object is actually an immutable struct with no internal workings. A need to change it to add computed (or worse, mutable) fields is probably a code smell.

mcormier• 17 years ago

Although I do agree that you shouldn't reassign a parameter I don't agree with using the final keyword everywhere. Any decent koder knows not to modify a parameter. If you want to enforce something like this then parse the code on check in and refuse the check in if a parameter is modified. Don't bloat the kode with a reactionary workaround.

scott_s2• 17 years ago

I program extensively in C++, not Java. I'm in the habit of using the const qualifier wherever appropriate - even if it's a local variable. It's an easy way to tell myself, others and the compiler that what I'm declaring isn't actually a variable, but a named value.

I don't see how using a const or final qualifier where appropriate increases bloat.

profquail• 17 years ago

So having to write extra code to extend your versioning system to parse whatever language your code is in and then check it to see if you've altered a variable value doesn't increase bloat, but adding the 'final' keyword does?

There are other problems with that idea, the first of which is that if someone else takes your code and extends it (say, for an open source project) they won't have the same "checking system" that you have, and so it won't catch their mistakes (while using "final" would). Also, I'm not a Java programmer (I mostly use C# or C), but marking classes/methods/variables in C# as 'sealed', 'final', 'static', etc. actually increases the running speed of that program on the CLR because it is able to skip some safety checks on the IL code when it is executed; I don't know that the JVM does that, but it might be worth looking into.

gdp11• 17 years ago

Most JVM implementations that I am aware of do sane things with respect to optimisation of immutable values.

Tichy• 17 years ago

I would use final if something is final because it would also help to understand the code. It is a piece of information that something is final.

Don't forget that final things can still be changed, though.

somethingFinal.setName("teehee"); is still possible even if somethingFinal is final.

gdp11• 17 years ago

Sure, but that would be deliberately going against the tips in the article. The idea is to not mutate values, rather, you instantiate new objects to store new values.

fogus3• 17 years ago

"parse the code on check in and refuse the check in if a parameter is modified"

This would be know as really-really-late-binding.

tezza2• 17 years ago

final ... ah yes, the old final.

Just remember that final is a signal to the compiler that it can perform certain optimizations on your code. This includes inlining the value.

So if you use

  public static final KEY="value1";

you can get inconsistent class files if you change the value, the copy classes that use KEY 'variable' across selectively.

This is most ant webapp and J2EE compiling workflows.

gdp11• 17 years ago

That sounds like really broken compiler or build script behaviour, rather than something intrinsically wrong with the use of final.

tezza2• 17 years ago

  When the compiler sees a final method call it can 
  (at its discretion) skip the normal approach of inserting code

http://www.codeguru.com/java/tij/tij0071.shtml

JulianMorrison2• 17 years ago

What makes me laugh is the commenter defending getters and setters as encapsulation.

No, what getters and setters are is a huge verbose door cut through your encapsulation, turning a class into a mere vending machine.

bkudria2• 17 years ago

Agreed. Probably his confusion stems from the fact that Java can expose properties directly. Eww.

_giu• 17 years ago

"The Java concurrency primitives like locks and synchronized have been proven to be too low level and often to hard to use"

synchronized is not hard to use. it's rather not a good practice to use it, since it will slow down code massively.

gdp11• 17 years ago

Concurrency in general is hard. You'll find that most uses of concurrency in production systems is restricted to very specific patterns. This is probably not a conscious decision, rather it's just very likely that straying too far from very simple models of interaction between concurrent processes is actually just beyond the intellectual scope of most people. I do concurrency theory for a living, and concurrency primitives in Java still give me nightmares.

uriel• 17 years ago

Concurrency is hard only if you use the common 'pthread-like' model. There are much better alternatives like Erlang and CSP ( http://books.cat-v.org/computer-science/csp/ )

zmimon• 17 years ago

Actually synchronized is not that expensive in itself. Especially in modern implementations it's not bad at all. It always used to amuse me how Java developers would go to contortions trying not to synchronize a method and then they'd fill it up with calls to things like Vector (every method synchronized!), StringBuffer (yep, every method synchronized!) and any number of other calls that are synchronized in the default JDK.

bkudria2• 17 years ago

What's so great about "Fluent" interfaces? If a language supports named parameters, they're inappropriate, no?

(Yes, I know Java doesn't have named parameters, although it and many other languages that don't have it have a work-around with assignment. this is a general question.)

jrockway2• 17 years ago

Fluent interfaces suck. Mutating objects is not acceptable, especially when you should pass the correct stuff to the constructor.

But this is Java, and it is the only way to cleanly allow inheritable initargs.

(Perl/Moose and CLOS get this very right. I only use setters in those languages in very, very rare occasions, and it is usually because I am hacking around something messy.)

dcminter• 17 years ago

This is one programmer's opinions dressed up as a definitive list. We might as well be discussing bracing preferences - always futile without evidence.

For what little it's worth:

1. Minor benefit as noted. Most devs don't do this. Note that in point 3 his sample loop doesn't declare the loop item final so I doubt he does it all that often either.

2. Ok so far as it goes.

3. What objective benefit am I supposed to get here? If we're pulling preferences out of our bums, I'll go for meaningful names in loop variables thanks.

4. Says who? AT&T braces for the win!

5. Not my preference. Fails the YAGNI principle certainly (which he's apparently in favour of in point 2).

6. Who says it's too hard to use? For simple threading problems the existing tools are more than adequate.

7. Again, what benefit does this convey? It's used in a few places in Java (StringBuffer/Builder) but hasn't proven popular more generally. I suspect there are good reasons for that.

8. Not wildly unreasonable, but Getter/Setter pairs often turn out to be necessary in fairly short order.

KirinDave4• 17 years ago

Bizarre advice. Throw away the mutable aspects of Java to try and code in this "new hotness", a pale echo of an OCaml-esque style of programming. In the process you make code that is neither as declarative as functional code, nor elegant as Java code. Stop trying to code like another language and use another language.

That's enough for me to discard this article as chaff, but considering it even further, has anyone stopped to ask how the Java runtime and compiler handles these changes? Making new classes instead of mutating existing ones doesn't strike me as an efficient use of the system.

Finally, I am so sick of people lamenting being "trapped" in Java. This nonsense of being "trapped" is just a shield for people who don't want to go through the hassle of really using a different language. If I can squeak new languages in at Lockheed Martin on a huge spacerange project who's spec was literally conceived when I was still in diapers, then anyone can do it anywhere if they have the will.

cturner• 17 years ago

In some spaces (financial, perhaps military) running the JVM is the only sensible thing to do. It has special status that allows you to skip steps at audit, which allows your customers to install it, it allows you to use libraries and it's really good for cross-platform so long as you don't care about GUIs (and with everyone using web these days, there's no reason to care about GUI).

tjmc• 17 years ago

True, but who's to say you can't use another language in the JVM - eg. JRuby, Jython or Clojure

fhars• 17 years ago

The runtime system seems to be fine with this, at least the results for scala code (which compiles to bytecode consisting of many small, mostly immutable classes with shot lived instances) indicate that this style of programming hits a sweet spot for the JIT compiler and the GC (at least for sun's server VM) which has a far easier time inlining things than with code consisting of few big classes with long lived objects.

igorgue• 17 years ago

Python is newer than Java? :D

tetha2• 17 years ago

In fact, Python appeared around 1991, while the official Java Programming Language appeared around 1995 ;)

mahmud2• 17 years ago

But Python evolves fast! Every 3 years GvR finishes a chapter of SICP and Python gets better.

Next-gen Java Programming Style

Related Stories