Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'll be specific: Java 8 is promised to bring lambda expressions as well as method and constructor references among other things. As a Java developer I'm super psyched about that.

In my day to day programming I see more and more opportunities where using these features would greatly simplify code that would otherwise be very verbose and tedious. In lieu of method and constructor references I started using more and more reflection and plan to migrate those code paths to Java 8 as soon as possible. I use special comments (like the well known TODO comments: JAVA8) that can be used by the IDE or grepped easily in order to find the relevant places. I also test all those cases extensively to make sure they work.

But still I have to wonder whether it's good to do it like that. Is it acceptable to produce a little more brittle code now that will eventually become robust again? GA for Java 8 is September 2013 so it's not too far in the future (provided the release date doesn't slip).

A kinda general example would be something like this: I want to create some container objects and fill them with data from a database. If I were to use the standard Java approach, it could look like this:

class ContainerService {
  private Database database;
  private final Map, ContainerInitializer> INITIALIZERS = new HashMap();

  {
    INITIALIZERS.put(Foo.class, new FooInitializer());
  }

  public Container getContainer(Class cls) {
    return INITIALIZERS.get(cls).create();
  }

  interface ContainerInitializer {
    Container create();
  }

  class FooInitializer implements ContainerInitializer {
    Container create() {
      return new Container(database.getFoo());
    }
  }
}

The reflective code is

class ContainerService {
  private Database database;
  private final Map, String> INITIALIZERS = new HashMap();

  {
    INITIALIZERS.put(Foo.class, "getFoo");
  }

  public Container getContainer(Class cls) {
    Method m = Database.class.getMethod(INITIALIZERS.get(cls));
    return new Container(m.invoke(database));
  }
}

Note how all the intermediate interfaces and classes fall away.

The Java 8 variant is something along the following lines:

class ContainerService {
  private Database database;
  private final Map, ContainerInitializer> INITIALIZERS = new HashMap();

  {
    INITIALIZERS.put(Foo.class, database::getFoo);
  }

  public Container getContainer(Class cls) {
    return new Container(INITIALIZER.get(cls).create());
  }

  private interface ContainerInitializer {
    Container create();
  }
}

This is slightly longer again but has type safety. Also it's trivial to get from the prepared code to the final code using method references.

Of course the example is a bit simple. Imagine having a lot of types the container could contain. In the first method, there would be an extra class for each of them. In the other two methods, only data has to be added. It keeps everything so much simpler.

share|improve this question
1  
would you mind providing an example of "preparatory" code, along with how would it look like if you didn't expect Java 8 to come soon? –  gnat Feb 18 '13 at 14:13
1  
@gnat: I added an example. I hope it illustrates the point. –  musiKk Feb 18 '13 at 14:32
    
Java 7 EE is not out there yet (it entered review just in January). Targeting Java 8 with what looks to be an EE app may be getting ahead of yourself. –  MichaelT Feb 18 '13 at 14:41
3  
I guess the real question is: what kind of strange company are you working in that starts to develop for a language that won't be released for at least 6 months but refuses to let you use a language like Scala that has been out for a decade? –  Jörg W Mittag Feb 18 '13 at 15:03
4  
Is it acceptable to whom? If it's code you're writing for your own project, do whatever you want. If it's code you're writing for your employer talk with your manager, colleagues, or whoever determines what is and isn't acceptable for code in your organization. –  Caleb Feb 18 '13 at 15:34
show 4 more comments

closed as not constructive by gnat, Martijn Pieters, Glenn Nelson, Walter, Jim G. Feb 20 '13 at 0:45

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers

up vote 37 down vote accepted

Don't fall for the chant of sirens.

Their song talks about new features and performance improvements, but all you get by listening to that, is a neverending stream of pain, delays, procrastination, and deployment woes.

Write for what exists. The rest is mere speculation.

share|improve this answer
15  
Moreover, temporary codes tends to become permanent after a while –  arnaud Feb 18 '13 at 14:46
1  
I'm glad some people still have hope that that day will eventually arrive. I work with 13 year old code. Lol. –  Seer Feb 18 '13 at 15:01
5  
You 'fear' the popular answer. Maybe there's a reason it's popular. –  Jan Doggen Feb 18 '13 at 15:14
3  
@JanDoggen: Oh my. Don't take it too literal. –  musiKk Feb 18 '13 at 16:23
1  
+1. You are proposing to (1) do extra work now, and then (2) at some future point do some more extra work, in the hopes that (3) at some hypothetical far-future point you will need to change this code again, and you can maybe save some time. Instead save some time right now, by not doing any of the extra work! Profit! –  MarkJ Feb 19 '13 at 12:39
show 4 more comments

I agree with @ZJR's answer, but if you want to go ahead you can probably encapsulate this into a MethodReference class of some sort. With luck you might be able to gain type safety by juggling just one place when Java 8 comes along.

Boost basically does this before C++11. Certain features closely resembles the proposed syntax for C++11 to ease transition.

share|improve this answer
add comment

I share ZJR's opinion that you should stick to what is available today and develop for Java 6 or 7, if that is what you are using now: always use the tools that you have now for what they are, not for what they might be in the future.

I would add that if you really like anonymous functions and other functional-language idioms, you should consider switching to Scala, Clojure, or another language that already exists and fully supports such idioms, instead of waiting for Java to support a few of those idioms some time in the future. Otherwise, when you have your nice lambda expressions in Java 8, you might learn about pattern matching and start missing that (maybe you will get it with Java 10?) And then you will hear about currying or richer type-inference features, and will have to wait again.

So, I would stick to Java 6 for doing your object-oriented programming and switch to a language that truly supports functional programming if you wanted to do proper functional programming or a mix of object-oriented and functional programming. In other words, don't stick to Java if this language is not providing the combination of features that you are looking for.

And I also agree with "Don't fall for the chant of sirens.": I think Oracle is introducing some FP into Java (among other reasons) to keep selling Java to people who are not really interested in FP (otherwise they would be using a real FP language already) but do not want to be considered uncool for not knowing FP.

In my opinion, it is perfectly OK to stay out of this hype and continue to use purely object-oriented languages (like Java 6) if one feels comfortable with them. And if you write proper object-oriented code, it will not be "mediocre code".

share|improve this answer
add comment

I think the answer to this question most likely depends upon the situation in particular which you're dealing with. In terms of "day to day programming," does this consist of your job? Hobbyist/personal work, perhaps? If it's the latter, I don't necessarily think it to be a poor idea to look ahead in regards to refactoring and improving your code base, if you have the time -- attempting to improve upon your own work is never a bad thing. On the other hand, if it's a work scenario, even if you're a project manager you'd still have to run such thoughts by your peers to get their input. However, because these features don't exist yet, unless you have nothing else on your plate, it could be a very large waste of time and resources because none of the features really exist.

It's certainly something to think about, and there are a few ways in which you could handle it. You mention being able to make use of TODO comments where Java 8's features could be applied. You could also consider branching/forking a project entirely and writing makeshift pseudocode (assuming that the lambda syntax in Java 8 isn't finalized yet) in places where you might want to improve it in the future. Again, though, it brings up the aforementioned concerns of time and effort.

share|improve this answer
    
I definitely am going to ask my team lead and probably others for thoughts on this. Incidentally the prepared code doesn't really waste time. Quite the contrary: it's about as concise as the final solution is going to be. It's just type safety that's lacking. –  musiKk Feb 18 '13 at 14:34
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.