Lombok: Getter and Setter in interface?

[lucalas]

Good mornig, is there a way to integrate @Getter and @Setter into a interface?
Example:

public interface example{
    @Getter @Setter int variable;
}

---

public class exampleClass implements example{
   @Getter @Setter int variable;
}

or something like this.
Thanks.

[omega09]

What code would you have them generate that they don't generate already?

[lucalas]

We would like to write @getter and @setter into interface instead of getFoo() and setFoo(), whereas we have a lot of attributes to be expose!

[omega09]

Still confused. You can already write @Getter and @Setter for an interface field foo. They generate methods: public abstract <type> getFoo(); and public abstract void setFoo(<type> foo);. Can you please write what the generated code of your example

public interface example{
    @Getter @Setter int variable;
}

should look like?

[lucalas]

Eclipse return me an error when i write this piece of code

public interface example{
    @Getter @Setter int variable;
}

this is the error "_The blank final field variable may not have been initialized_" it's defined like a final variable, but it isn't what i would.

[Maaartinus]

You'll get the same error without Lombok, too. Interfaces allow only constants. You'd need Lombok to remove the field and to generate the accessors.

This sounds like an interesting feature, but possibly not common enough. AFAIK this is not implemented yet and I can't see it in the changelog either.

I added an initializer expression to variable so the error disappeared. Now, In my Eclipse 3.8.1 with Lombok 1-16.8, the field gets marked as static final and a getter and a setter get generated as abstract methods. This doesn't look like a sensible behavior.

[lucalas]

So if I marked as static final, I'm able to use the abstract generated method? i didn't think about it, perfect!
Anyway I think that it could be an intresting feature to implement, if it's possible.

[omega09]

@lucalas, let me clear this up a bit because it seams you are missing some details. Any field in an interface is automatically public static final, that is, a constant. This is why the example you gave initially was confusing and I tried to get you to write the result you wanted.

Annotating these fields adds public abstract methods like I showed above. You would need to implement them in a the implementing class. A setter is useless because the field is a constant, unless you declare a field with the same name in the class and refer the generated methods to it, and you have no way to enforce that field declaration. Furthermore, you would be left with a meaningless public constant which isn't supposed to be used.

You could generate a getter for the constant field in the interface if the method would be modified to default, something I do not recommend. What I think you want is to force the class to have a getter and setter method. That is, what you want is an automatic way to generate this:

interface MyInter {
    int getMyInt();
    void setMyInt(int myInt);
}

which kind of forces

class MyClass implements MyInter {
    @Setter @Getter private int myInt;
}

The problem is that there is no field in the interface to annotate. That means that the best you could ask for is something like:

@Getter(of="myInt") @Setter(of="myInt")
interface MyInter

which will generate the above abstract interface methods and possibly the concrete, normal, getter and setter methods for any implementing class. That will force the programmer to write the appropriate field declaration.

Does that make sense to you?

[Maaartinus]

The problem is that there is no field in the interface to annotate.

IMHO what the OP was expecting from this example

public interface MyInterface {
    @Getter @Setter int x;
}

namely a transformation into

public interface MyInterface {
    int getX();
    void setX(int x);
}

i.e., the generation of the accessors and the removal of the field is reasonable.

The fact that all fields in an interface are effectively static final is irrelevant here, as the field only exists as a placeholder the annotations can be placed on.

[lucalas]

@omega09 I understand your concerns, and I know that i can declare only a static final field in a interface, my question may seem a bit strange, but if you read last @Maaartinus answer maybe it's more clearly what i would like to do.

The fact that all fields in an interface are effectively static final is irrelevant here, as the field only exists as a placeholder the annotations can be placed on.

I don't really need a field in interface, it's something like a placeholder, nothing more, because i need the two methods get and set.

Have getter and setter help me to have a neater code! (or maybe because i'm too lazy to write get and set method for all fields ahahah)

Maybe my question it wasn't clear, sorry!

[omega09]

IMHO what the OP was expecting from this example

That may very well be and it seems that you're right, but I wish the "this generates that" section would have been written in the initial post and save all the guesses.

the removal of the field is reasonable.
the field only exists as a placeholder the annotations can be placed on.

I would be glad if this is the case and this feature can be implemented the way you mentioned. Did you ever see Lombok "removing" typed code?

[rspilker]

As already mentioned, the current behavior is that Lombok generates static getters and setters for the static field. Although one could argue that that is not as useful, we will not fix that, breaking other people's code, without a sufficient reason.

We technically _could_ trigger on uninitialized fields, generate the interface methods and remove the field. But I am afraid that just the fact that the field has an initializer modifies the static-ness might be confusing.

Also, Lombok can only do its job if the java file was syntactically correct. And I am afraid that the parser for interfaces already doesn't allow for uninitialized fields, or might no longer in a future update.

[rspilker]

One more thing, although Lombok has a way to generate javadoc, for interfaces I think I would prefer to see the javadoc in the code.

And it is just method signatures. So it really doesn't save that much code.