Re: Does final serve any purpose?

Discussion in 'Java' started by Kevin McMurtrie, Oct 14, 2010.

  1. In article <>,
    Spud <> wrote:

    > Does the final keyword serve any purpose, except to make constants constant?
    >
    > It used to be a hint to the JVM that it could make certain
    > optimizations, but I don't think that's true any more.
    >
    > I use it only to create "private final static" quasi-constants, but
    > nowhere else. Yet I see lots of code out there that sprinkles it
    > liberally everywhere.


    There still might be cases where it causes optimization because one of
    the HotSpot optimizations is not spending too much time analyzing large
    blocks of code before compilation.

    In addition to other things mentioned, it's sometimes critical for code
    maintenance. Objects used as lookup keys must be immutable or the
    structure that they're in will be damaged. It's best to enforce that
    during compilation rather than be careful and hope for the best.
    --
    I won't see Google Groups replies because I must filter them as spam
    Kevin McMurtrie, Oct 14, 2010
    #1
    1. Advertising

  2. Kevin McMurtrie

    Arne Vajhøj Guest

    On 14-10-2010 11:31, Kevin McMurtrie wrote:
    > In article<>,
    > Spud<> wrote:
    >> Does the final keyword serve any purpose, except to make constants constant?
    >>
    >> It used to be a hint to the JVM that it could make certain
    >> optimizations, but I don't think that's true any more.
    >>
    >> I use it only to create "private final static" quasi-constants, but
    >> nowhere else. Yet I see lots of code out there that sprinkles it
    >> liberally everywhere.

    >
    > There still might be cases where it causes optimization because one of
    > the HotSpot optimizations is not spending too much time analyzing large
    > blocks of code before compilation.
    >
    > In addition to other things mentioned, it's sometimes critical for code
    > maintenance. Objects used as lookup keys must be immutable or the
    > structure that they're in will be damaged. It's best to enforce that
    > during compilation rather than be careful and hope for the best.


    That is not a good case for final.

    Final does not protect the object only the ref.

    And to make the object immutable then don't provide any
    setters.

    With no setters the final is not needed and having both setters
    and final fields will not compile.

    Arne
    Arne Vajhøj, Oct 14, 2010
    #2
    1. Advertising

  3. Kevin McMurtrie

    Lew Guest

    Kevin McMurtrie wrote:
    >> In addition to other things mentioned, it's sometimes critical for code
    >> maintenance. Objects used as lookup keys must be immutable or the
    >> structure that they're in will be damaged. It's best to enforce that
    >> during compilation rather than be careful and hope for the best.


    Arne Vajhøj wrote:
    > That is not a good case for final.


    On the contrary, it's an excellent use case for 'final'.

    > Final does not protect the object only the ref.


    And the object in turn is protected by its own use of 'final'. Finality is
    spread from core to surface layer by layer by use of 'final' at each layer.

    It's disingenuous to say that 'final' is not useful simply because its scope
    is intentionally limited. 'final' *does* protect the object as well as the
    reference if it's used properly, i.e., at every layer. *Incorrect* use of
    'final' will protect only the reference but not the object.

    > And to make the object immutable then don't provide any
    > setters.


    Spoken in complete disregard for the maintenance portion of the class's
    lifecycle. 'final' protects for the future as well as the present.

    That doesn't make the object immutable anyway, since internal methods can
    mutate the state without 'final' protection. 'final' is a compiler-enforced
    prohibition against changes in an object's state even by the object itself.

    Furthermore, compile-time constants, for which 'final' is required, have
    special semantics, so at least there there is a value.

    > With no setters the final is not needed and having both setters
    > and final fields will not compile.


    Which is evidence of the usefulness of 'final'. You provide evidence for its
    value and claim it as proof that you don't need 'final'. Strange.

    The point of 'final' is that it raises a compiler error when you combine it
    with a setter, whereas your supposedly "immutable" class will silently allow a
    future developer to add a setter and destroy your immutability, which as
    stated above didn't exist anyway. 'final' lets you catch that contradiction
    at compile time, a clear advantage.

    You have to consider that a successful class will spend the largest part of
    its life in maintenance, not development. 'final' is a tool that lets you
    control and simplify maintenance, and prevent future errors. Way too many
    coders (I will not dignify them with the sobriquet "developers") code without
    regard for the largest part of their artifact's life or for the future
    programmers on whom they inflict their carelessness and unprofessionalism.

    --
    Lew
    Lew, Oct 15, 2010
    #3
  4. On Thu, 14 Oct 2010 19:35:43 -0400, Lew wrote:

    > The point of 'final' is that it raises a compiler error when you combine
    > it with a setter, whereas your supposedly "immutable" class will
    > silently allow a future developer to add a setter and destroy your
    > immutability, which as stated above didn't exist anyway. 'final' lets
    > you catch that contradiction at compile time, a clear advantage.


    I have to mostly agree with Lew here. I say "mostly" because it won't
    actually stop a determined future developer from adding a setter. What it
    WILL do is signal clearly that the field's immutability is not just an
    accidental feature of the current version of the class, but a planned and
    deliberate one that one changes at one's peril. That future developer, if
    at all competent, might at least hesitate and perhaps look to see if,
    say, the field is used in computations in equals() and hashCode() or
    something. He may think carefully about whether his goal can be achieved
    without adding the ability to mutate that object; perhaps it will suffice
    to add a method that makes a copy that has a change, for instance, while
    leaving the original unmodified. And if mutation truly is needed, he
    knows to be on the lookout for code elsewhere in the system that will
    also need to be changed to cope with the mutations because it formerly
    assumed objects of that kind to be immutable.
    ClassCastException, Oct 15, 2010
    #4
  5. In article <4cb76710$0$23757$>,
    Arne Vajhøj <> wrote:

    > On 14-10-2010 11:31, Kevin McMurtrie wrote:
    > > In article<>,
    > > Spud<> wrote:
    > >> Does the final keyword serve any purpose, except to make constants
    > >> constant?
    > >>
    > >> It used to be a hint to the JVM that it could make certain
    > >> optimizations, but I don't think that's true any more.
    > >>
    > >> I use it only to create "private final static" quasi-constants, but
    > >> nowhere else. Yet I see lots of code out there that sprinkles it
    > >> liberally everywhere.

    > >
    > > There still might be cases where it causes optimization because one of
    > > the HotSpot optimizations is not spending too much time analyzing large
    > > blocks of code before compilation.
    > >
    > > In addition to other things mentioned, it's sometimes critical for code
    > > maintenance. Objects used as lookup keys must be immutable or the
    > > structure that they're in will be damaged. It's best to enforce that
    > > during compilation rather than be careful and hope for the best.

    >
    > That is not a good case for final.
    >
    > Final does not protect the object only the ref.
    >
    > And to make the object immutable then don't provide any
    > setters.
    >
    > With no setters the final is not needed and having both setters
    > and final fields will not compile.
    >
    > Arne


    A lookup key is typically made of several primitive (or primitive-like)
    fields marked as final. That's a good case for 'final' to me.
    --
    I won't see Google Groups replies because I must filter them as spam
    Kevin McMurtrie, Oct 15, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shawn
    Replies:
    2
    Views:
    573
    Shawn
    Jun 24, 2005
  2. JFCM
    Replies:
    4
    Views:
    5,731
  3. Hattuari
    Replies:
    11
    Views:
    834
    Julie J.
    Feb 26, 2004
  4. Tom Anderson

    Re: Does final serve any purpose?

    Tom Anderson, Oct 13, 2010, in forum: Java
    Replies:
    4
    Views:
    259
  5. Peter
    Replies:
    8
    Views:
    310
    Jorgen Grahn
    Dec 29, 2012
Loading...

Share This Page