getter/setter naming conventions

[LucDC]

Hi all,

I am having a problem with the naming of Lombok's getters/setters.

For example the following:

private CUDao cUDao;

lombok gives me:

public CUDao getCUDao() {

return cUDao;

}

public void setCUDao(CUDao cUDao) {

this.cUDao = cUDao;

}

I expect (eclipse/intelliJ suggests) :

public CUDao getcUDao() {

return cUDao;

}

public void setcUDao(CUDao cUDao) {

this.cUDao = cUDao;

}

It seems like lombok does not follow the same naming conventions.

Is this deliberate? why so?

thanks!

[Martin Grajcar]

No idea where this crazy convention come from, but this snippet

static class Demo {

    int cUDao;

}

public static void main(String[] args) throws Exception {

    new PropertyDescriptor("cUDao", Demo.class).getReadMethod().getName();

}

throws an exception saying

java.beans.IntrospectionException: Method not found: isCUDao

Note the capital "C".  So Lombok seems to be compatible with java.beans.PropertyDescriptor, which should be compatible with the beans crap specification, shouldn't it?

Note that adding an Eclipse generated getcUDao doesn't change anything, but adding @Getter does.

Note also the "is" prefix in the message. I'm afraid, deprecating the whole java.beans package is the only way to keep sanity.

[LucDC]

The problem I am having is with spring autowiring by name.

The class contains private CUDao cUDao; with lombok getters/setters and gives the following error:

org.springframework.beans.NotWritablePropertyException: Invalid property 'cUDao' of bean class [com.xxx.yyy.ContractDaoImpl]: Bean property 'cUDao' is not writable or has an invalid setter method. Did you mean 'CUDao'?

If I overwrite the getter/setter with my custom getcUDao() and setcUDao(...) it works.

Spring seems to expects a different setter as lombok provides? 

Note that I am stuck on Spring 2.0.x.

[Reinier Zwitserloot]

We're going to stick to bean spec. If spring doesn't, it's their bug I'm afraid.

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[LucDC]

I am not entirely sure you are right in following the bean spec.

If both Eclipse and Netbeans and IntelliJ do it differently, it gets really suspicious.

See:

http://dertompson.com/2013/04/29/java-bean-getterssetters/

http://stackoverflow.com/a/16146215/1216191

It is not my decision to make of course...

[Reinier Zwitserloot]

I assume this was you?

https://code.google.com/p/projectlombok/issues/detail?id=722

issue accepted, you've given plenty of proof we're doing this wrong. Roel's back, development on lombok should pick back up a bit :)

On Tue, Aug 12, 2014 at 2:09 PM, LucDC <luc.de...@gmail.com> wrote:

http://stackoverflow.com/a/16146215/1216191

.... well, that's hard to deny.

When you're right, you're right. Even though it is technically a breaking change, I think I'm willing to risk it, so to speak. 

 --Reinier Zwitserloot

[LucDC]

Glad to hear the issue has been accepted. No more getters and setters I have to manually add. ;-)

I am glad to help!

Op donderdag 14 augustus 2014 03:00:31 UTC+2 schreef Reinier Zwitserloot:

I assume this was you?

No I didn't write that issue, but it does nicely sum up the problem.

 

issue accepted, you've given plenty of proof we're doing this wrong. Roel's back, development on lombok should pick back up a bit :)

Nice! 

Luc

[Leon Blakey]

Can this case change be a config option? Most people do not touch bean spec, fancy property descriptors, or spring magic and have always assumed the current behavior for a few years. Forcing this change through as default behavior is going to break a lot of APIs.

--

[LucDC]

When you change to a newer lombok version, this means you have access to the source code?

Worst case scenario is that lombok will now generate getter/setter different for those specific fields.

This will break some files using the old getter/setter and will be picked up by the compiler.

You change the code calling these getters and setters and everyone is happy?

bloating lombok with extra config will only make it more confusing for (new) users?

[Leon Blakey]

And what about those people that built libraries with a public API? Saying the library and every person that depends on that library needs to change their code that's used the current case convention for years seems a little crazy.

Besides, this is the entire reason the config file was created: Instead of bloating the annotation parameters with various small changes, people can have their own config file to suit their project needs.

Weather this new convention is the default isn't up to me, but there should at least be a config option.

--

[Martin Grajcar]

On Thu, Aug 14, 2014 at 2:33 PM, LucDC <luc.de...@gmail.com> wrote:

When you change to a newer lombok version, this means you have access to the source code?

Worst case scenario is that lombok will now generate getter/setter different for those specific fields.

This will break some files using the old getter/setter and will be picked up by the compiler.

You change the code calling these getters and setters and everyone is happy?

This may not work, as the part using these accessors may not be available as a source or it may be some library using the other behavior. Even java.beans.PropertyDescriptor expects getCUDao rather than getcUDao. This comes from java.beans.NameGenerator.capitalize, which is not as "smart" as  Introspector.decapitalize.

bloating lombok with extra config will only make it more confusing for (new) users?

That's the advantage of the configuration that you don't get confused as you don't need to care about parts you don't touch. If you were right with your assumption that the changed behavior is perfect for everyone, then making it to default would mean that everybody would just ignore the option (and spend no more than a few seconds reading about it in case they stumble upon it somehow). But what if you're wrong?

While I'm personally oblivious to this convention, I'd say that such a configuration is necessary. Choosing between getCUDao and getcUDao is a very strange option, but the damage was already done by releasing the specification with its crappy and unclear rules.

[Reinier Zwitserloot]

Okay, well, now that java itself doesn't even know which strategy to use, we're going to NOT fix this. Clearly there are different schools of thought here, so there's no one clearly right answer.

_IF_ we were to rebuild lombok from scratch, faced with the evidence Luc has posted so far, we would have sided with his strategy (getcUDao()), but the very very _very_ tiny upside that has vs. lombok's current behaviour is not worth it compared to breaking behaviour, and this corner case is definitely not worth a config key in our opinion.

Sorry luc, you'll have to handroll your getters :(

[LucDC]

Sorry luc, you'll have to handroll your getters :(

 

Haha no problem! It is only a handful of getters. ;-)

Thanks anyways for taking the time to discuss!