1

I'm using the "final"-keyword for method-parameters like the "const"-keyword in C/C++ even if it's meaning in JAVA is not 100% the same as in C/C++. I do that mainly to easily distinguish between input- and output-parameters. Like here:

interface Test
{
   public void myMethod(final int input1, final float input2, SomeResults output);
}

When I then create an implemention of the interface (or abstract class) and let eclipse generate the overloaded methods eclipse will ommit all "final"-keywords which is really bad. There is an option within the SaveActions-Part of the Java-Editor settings but there I can just enforce eclipse to use "final" everywhere where it is possible which is definitely not my intention. How can I force eclipse to NOT IGNORE my "final"-keywords in interface methods or abstract methods and put them in generated method stubs of implementions and child classes instead?

Marc
  • 41
  • 4
  • 2
    It is not only "not 100% the same" as const - it is way more different. As a caller, it gives you literally no additional guarantees at all. The only thing it prevents is re-assingning the parameters within the method, but that is not visible to the caller anyway. – Hulk Oct 23 '20 at 12:59
  • Related: https://stackoverflow.com/questions/4162531/making-java-method-arguments-as-final – Hulk Oct 23 '20 at 13:00
  • Also, note that primitives are always passed by value anyways: https://stackoverflow.com/questions/40480/is-java-pass-by-reference-or-pass-by-value (so are references, but that is less obvious) – Hulk Oct 23 '20 at 13:02
  • 1
    Also note that using out-parameters is not really idiomatic in Java, especially for a `void` function - why not use a return value? – Hulk Oct 23 '20 at 13:09
  • As stated I use the "final" keyword only to clarify that a parameter is a "pure input" variable. Regarding that primitives will always be passed by value is known to me. – Marc Oct 23 '20 at 13:40
  • Ok. I doubt there is much tool support for that. As said, adding `final` at interface level does not really add any guarantees whatsoever, so it is often seen unnecessary clutter - or worse, giving a false sense of security. Some static analyzers tried to add annotations to help spotting modifications of paramers annotated as "@ReadOnly" or similar, but even that does not help against runtime issues. – Hulk Oct 23 '20 at 20:55
  • The current developement goes in the direction of adding features like [Record](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Record.html) and ValueTypes, but we will have to wait a bit until they are ready in one of the next few versions. – Hulk Oct 23 '20 at 21:03
  • The consensus is that as the only way to make something const in java is to make the type immutable, the correct way to guarantee not to modify something is to accept an immutable type. The rest is left to documentation. – Hulk Oct 23 '20 at 21:12

1 Answers1

1

How can I force eclipse to NOT IGNORE my final keywords in interface methods or abstract methods and put them in generated method stubs of implementations and child classes instead?

I don't think it is possible ... unless you are willing to modify Eclipse.

I am afraid that what you are doing doesn't have any effect.

As stated I use the final keyword only to clarify that a parameter is a "pure input" variable. Regarding that primitives will always be passed by value is known to me.

That is not what final means.

  1. All parameters are "pure input" ... in the sense that they are passed by value. There is no such thing as an "out" parameter in Java.

  2. Conversely, if a parameter's type is a reference type, then declaring it final does not stop the method body from mutating the actual parameter. In other words, it doesn't stop the method body from using the parameter to simulate an "out" parameter.

  3. In Java, declaring a formal parameter as final in an abstract method declarator doesn't have any meaning. It only has meaning if the method declarator is followed by a method body. (Then it means that the variable cannot be assigned to.) Therefore, it would be suspect if a tool (e.g. an Eclipse stub generator) were to place any meaning on the final in the the former context.

My advice would be not to place this unintended (by the Java designers) meaning on final, in either interfaces or in classes. If you want to express "this is not an "out" parameter, either do it in the javadocs, or invent a custom annotation to express it. (In the latter case, you could potentially implement a static checker to ensure that the method body does not mutate the parameter object.)

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216