Community
Participate
Working Groups
Hi all. Four a course project I have developed a plugin that helps manage the concern of object cloning in Java, using Eclipse. The plugin consists of two parts: 1. An Eclipse builder that detects four different code smells w.r.t. cloning: 1. Returning null from clone() 2. Never calling super.clone(). 3. Implementing clone() but not Clooneable or vice versa. 4. In a Java 5 project, not using the covariant return type for clone(). 2. A code generator very similar in style to "generate hashCode()/equals()" that allows to generate correct clone methods with selective deep copy of fields that have as declared type a reference type that also implements Cloneable. You can download the plugin and a report plus slides about it at the attached URL. My question is whether you would consider integrating this functionality into the main Eclipse build stream. I deliberately tried to make the implementation as consistent as possible with the current implementation of "generate hashCode() and equals()" in order to provide a similar look and feel and to allow for easy integration. The flip-side for me is that because of that I use a lot of internal APIs. Hence, integration into Eclipse would be very desirable from my point of view. Thanks in advance!
Moving to JDT/UI.
1. feels like new compiler warnings
Gets my vote. Anything that makes deep vs shallow clone as easy as selecting "generate clone()" would be a welcome addition.
Maybe file separate bugs for this. Checking would be in the compiler, code generation in jdt.ui. We will have a look at this in 3.4.
> Maybe file separate bugs for this. Checking would be in the compiler, code > generation in jdt.ui. Yes, I agree that this should be split. Checking and code generation are really separate. The only thing that combines them are the warning markers. Should I split this up or are you going to take care of this?
Best is if you do it, so it is clear who's suggestion it is. I expect that if JDT core likes the suggestion they would add it to the compiler directly, using the normal Java problem markers.
Ok, from now on, this bug is restricted to the code generation part of the plugin (bullet 2. from the original report). Bug 186135 will handle the related compiler checks.
Hey again. I was just wondering if this is going to make it into the 3.4 release. Can you tell? Thanks!
Yes, it is tagged as 3.4, so we still plan to do this.
Not for 3.4, sorry, this got lost. I'm also not sure that we really want to add the new wizard. Please understand that we are very careful when adding new features, as maintenance is costly.
Sure, no pressure. I (and others) can use it in form of a plugin in the meantime.
I came upon this plug-in and then this issue when I realized this wasn't already in the JDT! Regardless of whether it ends up in the JDT proper (which would be nice), is there a place that this type of plug-in can live more officially than a student account on a university server? Like an Eclipse "sanctioned" plug-in or the like? Is there a JDT Contrib type of project that gets vetted to prevent garbage or duplication but also doesn't need to bloat the base project...sort of like Apache's Commons project I guess...has the governance but not the maintenance?
Uh. Just noticed. Not sure why I thought that was a university server...oops. But the comment/question still holds barring the warped example.
> Not sure why I thought that was a university server...oops. I am confused. It is a university server.
I was going to just leave it alone, but since you are confused. I read your site...it talked of University activity. I assumed that as I wrote my initial comment. Then I was typing the URL for the update site and it didn't have .edu (which I guess is done here in the US, but not everywhere) and I visited the site and saw it was a research organization. So, I posted the oops comment. Then, two minutes later being bothered by the fact that I really felt it was a university I clicked to see the parent organization, which of course is the university. So...I realized my oops was unnecessary, but then it seemed like comment spam, so I just let it go. Sorry for all the confusion.
We won't work on this unless a good quality patch is attached to this bug report.
While this is in everone's thoughts, I thought I'd comment on performance and also efficacy. I've used this plugin, but stopped using it a while back. My recollection was that it didn't support incremental builds. Also, I've since read "Effective Java" which has some different views of what to do when cloning. So, if this is to be integrated, then I'd say that what is needed is: - a performance assessment, possibly keeping to having it as being a one-shot analysis (TPTP Analyser a better place??) - compatibility with different approaches. There are clearly bad "smells" that can be picked up, and may be a subset of what's implemented. - likewise, it would be good to allow people to specify their 'house style'. ...mmm... really seems like a Findbugs/TPTP feature. What aspects of this are the equiv of warnings like: variable is declared but never read? It would also need @SuppressWarnings support.
Neale please note that builder related comments should go into bug 186135 as this one is only about the clone method generation wizard.
