• As it says in several places throughout the article, this is an example. And a contrived one at that. (I even explain why I chose it but since this discussion has come up before I agree that it has not been a good one.) So saying that the main issue is storing a Future in a Set is missing the point.

    The main issue is that lambda expressions…[Read more]

  • Roughly a month ago, I summarised Brian Goetz’ peek under the hood of lambda expressions in Java 8. Currently I’m researching for a post about default methods and to my mild surprise came back to how Java han […]

    • Manipulating Futures or Lambdas as Sets makes no sense at all.

    • As it says in several places throughout the article, this is an example. And a contrived one at that. (I even explain why I chose it but since this discussion has come up before I agree that it has not been a good one.) So saying that the main issue is storing a Future in a Set is missing the point.

      The main issue is that lambda expressions have weaker identity guarantees than their alternatives (anonymous or inner classes) and that this is not immediately obvious.

      And that is totally fine. They are meant to express behavior not state, so equality makes little sense for them. At the same time performance can be improved if no guarantees are made which I guess is the reason why they weren’t.

      But this does not change the fact that it is a non-obvious property, which can lead to misunderstandings and errors. And unlike the caching mechanisms you allude to, author or readers of such “factory-lambda”-code may assume that they are creating multiple instances while they are in fact not. All this article is doing is discussing this so that its readers won’t fall into that trap should it ever present itself.

    • Why are you expecting different instances of lambdas to start with? What did you want to achieve with that?

      • > Why are you expecting different instances of lambdas to start with?

        Because this would be the most natural behavior for Java. You want to create something? You get a new instance. Also note, that he fact that the Future is created by a lambda is hidden from the APIs consumer.

        > What did you want to achieve with that?

        Nothing, I just played around. But I am sure that at some point some developer will want to achieve something and it might fail for non-obvious reasons.

  • Casting an instance to a type reeks of bad design. Still, there are situations where there is no other choice. The ability to do this has hence been part of Java since day one.

    I think Java 8 created a need to […]

    • I like the idea. “Not much” is right when it comes to how much these methods will be used, though. Would still be handy. I would probably make these as extension methods in Kotlin if I ever need them.

  • So, default methods… yesterday’s news, right? Yes but after a year of use, a lot of facts accumulated and I wanted to gather them in one place for those developers who are just starting to use them. And maybe eve […]

  • Previously, I talked about serialization in general. This one is much more focused and presents a single detail: the Serialization Proxy Pattern. It is a good, often the best, way to deal with many of the issues […]

    • Well written, however I have to disagree with the conclusion+advice. This pattern should only be used when absolutely required. It adds significant performance overhead (I am author of JDK compatible fast serialization, https://github.com/RuedigerMoeller/fast-serialization).
      Using this pattern for simple classes such as complex numbers is unnecessary overhead, don’t do that. Whenever overriding readObject/writeObject first consider Externalizable.
      The perception of having to execute constructor code upon deserialiuation is very wrong. Conceptually serialization means transmission of an already properly constructed Object, deserialization is NOT object construction, it should restore the state of the original object from the stream.
      This pattern should be used for the rare edge cases it was introduced for.

  • Wow, telling people to comment their fucking code really hit a nerve. The reactions covered the whole spectrum from “just read Clean Code, dude” to “maybe some comments but just a little” to “OMG yes.” […]

  • None taken.

    While this may seem like just another article about Optional I hope it does add something to the discussion. Namely, that Optional could be used everywhere and how that would change our relationship to null so we don’t have to “work around” it anymore. This is not typically found in other posts about it (e.g. the ones linked at the…[Read more]

  • Java 8 introduced a type Optional, which can be used to handle potentially missing values. It does so by wrapping a reference (which might be null) and providing some nice methods to interact with the value in […]

    • None taken.

      While this may seem like just another article about Optional I hope it does add something to the discussion. Namely, that Optional could be used everywhere and how that would change our relationship to null so we don’t have to “work around” it anymore. This is not typically found in other posts about it (e.g. the ones linked at the beginning). Also, the article was originally posted in October 2014.

      I can understand that you are asking about the date API, it seems to have been covered a little less than it deserves. But Lambdas? Come on, articles about them are legion! And in case you are interested in default methods, I would suggest this article of mine.

  • You’re the elite. You know Clean Code by heart, you dream of SOLID design, and you unit-test every line you write. Your code is so self-documenting you don’t even need to write comments!

    Then this rant is jus […]

  • So, Project Jigsaw… We already know quite a bit about it but have not yet seen the details of how it plans to deliver on its promises. This post will do precisely that and present the project’s core concepts and […]

  • In a recent post I explained why we can’t serialize Optional. But what if, after all that, we still really, really want to? Let’s see how to come as close as possible.
    Update
    This is part of a series of pos […]

  • With all this talk about why Optional isn’t serializable and what to do about it (coming up soon), let’s have a closer look at serialization.
    Overview
    This post presents some key concepts of serialization. It […]

  • In Java 8 some classes got a small note in Javadoc stating they are value-based classes. This includes a link to a short explanation and some limitations about what not to do with them. This is easily overlooked […]

  • You are right and this is a common argument in favor of Optional being serializable. I guess it was not important enough for the expert group. But a workaround is simple – see my post on how to serialize Optional.

  • Java 8’s new type Optional was met with different reactions and one point of criticism is that it isn’t serializable. Let’s have a look at the reasons for that. A future post will then show how to overcome that […]

    • You are right and this is a common argument in favor of Optional being serializable. I guess it was not important enough for the expert group. But a workaround is simple – see my post on how to serialize Optional.

  • Nicolai Parlog unlocked the achievement: Congenial Coder 4 years ago

  • “Most of the time you’d be dealing with an empty optional by using some default value and getting on with your life”
    “Other times a missing value is simply a error, so you should be blowing up anyway.”
    And sometimes (quite often actually), you’d like to do continue working on the value if it is there.

    Those use cases have a common theme: h…[Read more]

  • Hi Mani,

    thanks for your appreciation.

    Otherwise, see my tweet.

    so long … Nicolai

  • Nicolai Parlog unlocked the achievement: Voice Activated 4 years ago

  • Load More