StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
12807937
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
15
CommunityOwnedDate
CreationDate
2012-10-09T20:30:53.403
FavoriteCount
0
LastActivityDate
2018-03-26T21:34:13.060
LastEditDate
2018-03-26T21:34:13.060
LastEditorUserId
378151
OwnerUserId
378151
ParentId
3852091
PostTypeId
2
Score
668
ViewCount
0
LastEditorDisplayName
text
Body
Just started using Lombok today. So far I like it, but one drawback I didn't see mentioned was refactoring support. If you have a class annotated with <code>@Data</code>, it will generate the getters and setters for you based on the field names. If you use one of those getters in another class, then decide the field is poorly named, it will not find usages of those getters and setters and replace the old name with the new name. I would imagine this would have to be done via an IDE plug-in and not via Lombok. UPDATE (Jan 22 '13) After using Lombok for 3 months, I still recommend it for most projects. I did, however, find another drawback that is similar to the one listed above. If you have a class, say <code>MyCompoundObject.java</code> that has 2 members, both annotated with <code>@Delegate</code>, say <code>myWidgets</code> and <code>myGadgets</code>, when you call <code>myCompoundObject.getThingies()</code> from another class, it's impossible to know if it's delegating to the <code>Widget</code> or <code>Gadget</code> because you can no longer jump to source within the IDE. Using the Eclipse "Generate Delegate Methods..." provides you with the same functionality, is just as quick and provides source jumping. The downside is it clutters your source with boilerplate code that take the focus off the important stuff. UPDATE 2 (Feb 26 '13) After 5 months, we're still using Lombok, but I have some other annoyances. The lack of a declared getter & setter can get annoying at times when you are trying to familiarize yourself with new code. For example, if I see a method called <code>getDynamicCols()</code> but I don't know what it's about, I have some extra hurdles to jump to determine the purpose of this method. Some of the hurdles are Lombok, some are the lack of a Lombok smart plugin. Hurdles include: <ul> <li>Lack of JavaDocs. If I javadoc the field, I would hope the getter and setter would inherit that javadoc through the Lombok compilation step.</li> <li>Jump to method definition jumps me to the class, but not the property that generated the getter. This is a plugin issue.</li> <li>Obviously you are not able to set a breakpoint in a getter/setter unless you generate or code the method.</li> <li>NOTE: This Reference Search is not an issue as I first thought it was. You do need to be using a perspective that enables the Outline view though. Not a problem for most developers. My problem was I am using Mylyn which was filtering my <code>Outline</code> view, so I didn't see the methods. Lack of References search. If I want to see who's calling <code>getDynamicCols(args...)</code>, I have to generate or code the setter to be able to search for references. </li> </ul> UPDATE 3 (Mar 7 '13) Learning to use the various ways of doing things in Eclipse I guess. You can actually set a conditional breakpoint (BP) on a Lombok generated method. Using the <code>Outline</code> view, you can right-click the method to <code>Toggle Method Breakpoint</code>. Then when you hit the BP, you can use the debugging <code>Variables</code> view to see what the generated method named the parameters (usually the same as the field name) and finally, use the <code>Breakpoints</code> view to right-click the BP and select <code>Breakpoint Properties...</code> to add a condition. Nice. UPDATE 4 (Aug 16 '13) Netbeans doesn't like it when you update your Lombok dependencies in your Maven pom. The project still compiles, but files get flagged for having compilation errors because it can't see the methods Lombok is creating. Clearing the Netbeans cache resolves the issue. Not sure if there is a "Clean Project" option like there is in Eclipse. Minor issue, but wanted to make it known. UPDATE 5 (Jan 17 '14) Lombok doesn't always play nice with Groovy, or at least the <code>groovy-eclipse-compiler</code>. You might have to downgrade your version of the compiler. <a href="https://stackoverflow.com/questions/8524891/maven-groovy-and-java-lombok">Maven Groovy and Java + Lombok</a> UPDATE 6 (Jun 26 '14) A word of warning. Lombok is slightly addictive and if you work on a project where you can't use it for some reason, it will annoy the piss out of you. You may be better off just never using it at all. UPDATE 7 (Jul 23 '14) This is a bit of an interesting update because it directly addresses the safety of adopting Lombok that the OP asked about. As of v1.14, the <code>@Delegate</code> annotation has been demoted to an Experimental status. The details are documented on their site (<a href="http://projectlombok.org/features/experimental/Delegate.html" rel="noreferrer" title="Delegate Docs">Lombok Delegate Docs</a>). The thing is, if you were using this feature, your backout options are limited. I see the options as: <ul> <li>Manually remove <code>@Delegate</code> annotations and generate/handcode the delegate code. This is a little harder if you were using attributes within the annotation.</li> <li>Delombok the files that have the <code>@Delegate</code> annotation and maybe add back in the annotations that you do want.</li> <li>Never update Lombok or maintain a fork (or live with using experiential features).</li> <li>Delombok your entire project and stop using Lombok.</li> </ul> As far as I can tell, <a href="https://github.com/rzwitserloot/lombok/blob/master/src/delombok/lombok/delombok/Delombok.java" rel="noreferrer">Delombok doesn't have an option to remove a subset of annotations</a>; it's all or nothing at least for the context of a single file. I opened <a href="https://code.google.com/p/projectlombok/issues/detail?id=711" rel="noreferrer">a ticket to request this feature</a> with Delombok flags, but I wouldn't expect that in the near future. UPDATE 8 (Oct 20 '14) If it's an option for you, Groovy offers most of the same benefits of Lombok, plus a boat load of other features, including <a href="http://groovy.codehaus.org/Delegate+transformation" rel="noreferrer">@Delegate</a>. If you think you'll have a hard time selling the idea to the powers that be, take a look at the <code>@CompileStatic</code> or <code>@TypeChecked</code> annotation to see if that can help your cause. In fact, <a href="http://docs.codehaus.org/display/GROOVY/Groovy+2.0+release+notes#Groovy2.0releasenotes-A%E2%80%9Cstatictheme%E2%80%9Dforadynamiclanguage" rel="noreferrer">the primary focus of the Groovy 2.0 release was static safety</a>. UPDATE 9 (Sep 1 '15) Lombok is still being <a href="https://projectlombok.org/changelog.html" rel="noreferrer">actively maintained and enhanced</a>, which bodes well to the safety level of adoption. The <a href="https://projectlombok.org/features/Builder.html" rel="noreferrer">@Builder</a> annotations is one of my favorite new features. UPDATE 10 (Nov 17 '15) This may not seem directly related to the OP's question, but worth sharing. If you're looking for tools to help you reduce the amount of boilerplate code you write, you can also check out <a href="https://github.com/google/auto" rel="noreferrer">Google Auto</a> - in particular <a href="https://github.com/google/auto/tree/master/value" rel="noreferrer">AutoValue</a>. If you look at their <a href="https://docs.google.com/presentation/d/14u_h-lMn7f1rXE1nDiLX0azS3IkgjGl5uxp5jGJ75RE/edit#slide=id.g2a5e9c4a8_0104" rel="noreferrer">slide deck</a>, the list Lombok as a possible solution to the problem they are trying to solve. The cons they list for Lombok are: <ul> <li>The inserted code is invisible (you can't "see" the the methods it generates) [ed note - actually you can, but it just requires a decompiler]</li> <li>The compiler hacks are non-standard and fragile</li> <li>"In our view, your code is no longer really Java"</li> </ul> I'm not sure how much I agree with their evaluation. And given the cons of AutoValue that are documented in the slides, I'll be sticking with Lombok (if Groovy is not an option). UPDATE 11 (Feb 8 '16) I found out <a href="http://projects.spring.io/spring-roo/" rel="noreferrer">Spring Roo</a> has some <a href="https://stackoverflow.com/search?q=RooEquals">similar annotations</a>. I was a little surprised to find out Roo is still a thing and finding documentation for the annotations is a bit rough. Removal also doesn't look as easy as de-lombok. Lombok seems like the safer choice. UPDATE 12 (Feb 17 '16) While trying to come up with justifications for why it's safe to bring in Lombok for the project I'm currently working on, I found a piece of gold that was added with <code>v1.14</code> - The <a href="https://projectlombok.org/features/configuration.html" rel="noreferrer">Configuration System</a>! This is means you can configure a project to dis-allow certain features that your team deems unsafe or undesirable. Better yet, it can also create directory specific config with different settings. This is AWESOME. UPDATE 13 (Oct 4 '16) If this kind of thing matters to you, <a href="https://stackoverflow.com/users/18122/oliver-gierke">Oliver Gierke</a> felt it was safe to <a href="https://github.com/spring-projects/spring-data-rest/blame/897bc88d6922e755038a6a8e34ca25ace6a27689/spring-data-rest-webmvc/src/main/java/org/springframework/data/rest/webmvc/alps/RootResourceInformationToAlpsDescriptorConverter.java#L20" rel="noreferrer">add Lombok to Spring Data Rest</a>. UPDATE 14 (Sep 26 '17) As pointed out by <a href="https://stackoverflow.com/users/173149/gavenkoa">@gavenkoa</a> in the comments on the OPs question, <a href="https://github.com/rzwitserloot/lombok/issues/985" rel="noreferrer">JDK9 compiler support isn't yet available</a> (Issue #985). It also sounds like it's not going to be an easy fix for the Lombok team to get around. UPDATE 15 (Mar 26 '18) The Lombok changelog indicates as of v1.16.20 "<a href="https://projectlombok.org/changelog" rel="noreferrer">Compiling lombok on JDK1.9 is now possible</a>" even though <a href="https://github.com/rzwitserloot/lombok/issues/985" rel="noreferrer">#985</a> is still open. Changes to accommodate JDK9, however, necessitated some breaking changes; all isolated to changes in config defaults. It's a little concerning that they introduced breaking changes, but the version only bumped the "Incremental" version number (going from v1.16.18 to v1.16.20). Since this post was about the safety, if you had a <code>yarn/npm</code> like build system that automatically upgraded to the latest incremental version, you might be in for a rude awakening.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POIs it safe to use Project Lombok?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USSnekse
UserOwnerUserId
1. USSnekse
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COThanks I think this was the information the OP really wanted as opposed to a philosophical response.
 singulars
 PostPostId
 PO
 UserUserId
 USchaostheory
2. COThank you for updating this answer over time :)
 singulars
 PostPostId
 PO
 UserUserId
 USTwirrim

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.