Re: [project lombok] FieldNameConstants Experimental

444 views
Skip to first unread message

Robin Roos

unread,
Apr 15, 2021, 5:52:01 AM4/15/21
to project...@googlegroups.com
Hi Folks,

I picked up on Alex' message below and took a look.

Yes, I need this.  I am implementing Serializers for Hazelcast using their Serialization Model called "Portable", in which the field name is provided alongside its value.  That allows Hazelcast to do some optimisations, like querying the distributed cache against specific field values WITHOUT having to materialise the Java POJO first.

FieldNameConstants will allow me to code up the Serializer without using String tokens for each field name.  In my case the Serialization is non-Persistent, so I don't have to worry about field names becoming changed in the serialisation format.

I would definitely vote for this Experimental feature to be retained. 

Kind regards, Robin.

On 17 Mar 2021, at 13:32GMT, Axel-F B <axel.fred...@gmail.com> wrote:

Hi everyone! 

we really like Lombok and we just found the FieldNameConstants Feature, which is still experimental and has a call to provide Feedback ;-) 

So i just wanted to say I really like this Feature because it helps us in:
- consolidating these constants in a place where they belong automagically: the POJO itself
- making it compile time safe for refactorings to the fields
- prevent to type them by hand or place them anywhere else which makes way for human error

We use it a to provide Messages for Validation Errors, configure Mappers, and hopefully more to come.

Thanks for you work!
Axel

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/a31d8a95-7514-4abe-91bd-1f3599862156n%40googlegroups.com.

Robin Roos

unread,
Jan 12, 2022, 9:43:37 AM1/12/22
to project...@googlegroups.com
I wonder if perhaps the inner class "Fields" should instead be an enum called "Field" ?  

See below; attempting to avoid reflection, I can't do this with a "public static final String" but I could do this with an enum.

Robin Roos

unread,
Jan 12, 2022, 10:28:33 AM1/12/22
to project...@googlegroups.com
Easily reimplemented with if instead of switch.



On 15 Apr 2021, at 10:51GMT+1, Robin Roos <ro...@roos.uk.net> wrote:

Raja Chaitanya Rekapalli

unread,
Aug 7, 2023, 8:01:17 AM8/7/23
to Project Lombok
This is a very good feature to have for @FieldNameConstants. A couple of possible solutions could be:

1) An extension for the @FieldNameConstants to accept a value to format the field name as per a given pattern. For example, @FieldNameConstants(namePattern="<someRegexFormatPattern>")
2) An extension for the @FieldNameConstants to accept a value to convert the case like: @FieldNameConstants(nameCase="PascalCase"), @FieldNameConstants(nameCase="CamelCase"), @FieldNameConstants(nameCase="SnakeCase")

Something similar to this would provide a standard way to bridge between serialization/persistence to databases. 

Thanks.
Reply all
Reply to author
Forward
0 new messages