Re: [project lombok] Feature Request: Singleton pattern

[Marius Kruger]

see previous discussion here:
https://groups.google.com/forum/?fromgroups=#!topic/project-lombok/Rjs3W3D5Rus

I see lombok-pg has an @Singleton:
https://github.com/peichhorn/lombok-pg/wiki/%40Singleton

--
✝ Marius

[Reinier Zwitserloot]

Thanks for that link Marius.

Our opinion on this remains unchanged: Nice-to-have but falls in the abandonware feature camp (a feature we'd build, release with some fanfare, never actually use ourselves, and then 2 years someone files a bug against it, and some research by us shows that this bug most likely has been in lombok releases going back at least 6 months, thus concluding that nobody is using this feature much). We're trying to stay away from the abandonware as it's a drain on support resources, is by definition mostly a waste of our time, and it would effectively be writing checks (that it's stable and a good idea) that it can't cash.

Basically, features have to meet some minimum threshold of coolness and usefulness for us to take them on in the first place as no feature is 'free' (maintainance and the like, having to (re) implement on different platforms, rewriting based on changes to future java releases etc). @Singleton does not make the cut.

In case you are wondering what does: Mostly stuff we envision ourselves using daily.

Eh, why not, a status update on my (not Roel's, Robbert Jan's, or other core contributors) opinions on the current feature loadout (in order of how often I use it and how much I like it).

* val - I use this in almost every source file.

* @Cleanup - If I'm using resources, this is in my source file, every time. I like this far more than java7's try-with.

The above 2 are just part of java in my mind now, and I couldn't code my way out of a paper bag without either.

* @Data and friends - This shows up in most projects and is particularly great to avoid 'type abuse' where without lombok I would have kludged something with an array or an inappropriate type. i.e. classes that contain some fields, a @Data annotation, and absolutely nothing else. (This one includes @Getter, @ToString, etc)

* @SneakyThrows - #4; sees some 'production' use here and there, and gets used all the time when writing prototypes.

* @Slf4j - in some projects this is on almost every class, but then it is quite low impact.

from here there's an extremely sharp dropoff.

* @Getter(lazy=true). While cool, I never use this.

* @Synchronized. I rarely mess with threads on this level, and when I do, it's almost always with a synchronized(X){} code block and not with an entire synchronized method. I use this once a year maybe.

* @Delegate. As cool as it sounds in theory I just don't code with this. I think it's part of a wrong mindset on my part; Roel says he uses this quite a lot.

* onX (new in edge) - this isn't a personal thing for me, but then I have yet to start using guice in a serious project. I probably should have done that a long time ago, so that's on me. I have no doubt that it is necessary though.

* @ExtensionMethod - this is what we are working on now: To make it automatically 'just work' for all your projects whether you annotated your class or not, with appropriate facilities for you to tone down the magic if this is a little too much for you. The problem with this feature as it is right now is that there aren't enough useful classes in the JRE itself that you can extensionmethod in, and I don't have a simple thing I can toss into my ivy.xml to import what I want, so I'd have to write it myself for any given project and it's always easier to just call the actual static method I'm looking for instead of coding it up for any single instance where I'd like to use extension methods. Thus, to address this issue, we are currently working on a library with useful extensions and a way for you to configure, project-wide, that you'd just like them applied everywhere. Basically, you include this runtime library in your classpath in eclipse / when compiling with javac, and all extensions you want just work, no annotations needed.

 --Reinier Zwitserloot

--
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/groups/opt_out.

[Maaartin G]

On Wednesday, February 27, 2013 2:36:23 AM UTC+1, Reinier Zwitserloot wrote:

Our opinion on this remains unchanged: Nice-to-have but...

IMHO even nicer not to have. Singleton is a sort of anti-pattern. It's OK to use one or two in a small project (but then you need no lombok for them, do you?) and it's surely wrong to use dozens of them. For anybody feeling like needing many singletons, DI is the way to go. With something like

http://google-guice.googlecode.com/git/javadoc/com/google/inject/Singleton.html

you can effectively get a singleton, yet you can handle it like any other class in the tests.