Bug 201278 - JPDABreakpoint with protected constructor.
JPDABreakpoint with protected constructor.
Status: RESOLVED WONTFIX
Product: debugger
Classification: Unclassified
Component: Java
7.1
PC Linux
: P2 (vote)
: TBD
Assigned To: apireviews
issues@debugger
: API
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-24 13:59 UTC by Martin Entlicher
Modified: 2011-08-29 13:05 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments
The proposed API change. (3.71 KB, text/plain)
2011-08-24 15:38 UTC, Martin Entlicher
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Entlicher 2011-08-24 13:59:28 UTC
JPDABreakpoint class needs to be overriden by visual debugger breakpoints to reuse it's functionality. All JPDA breakpoint implementation classes extend the JPDABreakpoint class. Therefore we need the protected constructor to be able to extend it by visual breakpoint implementaion in debugger.jpda.visual module.
In addition to the constructor, we need fireJPDABreakpointChange and fillFilesForClass to be protected as well.

The session property getter and setter methods are used already by debugger.jpda module, therefore we're making them public with this API change.
Comment 1 Martin Entlicher 2011-08-24 15:38:53 UTC
Created attachment 110183 [details]
The proposed API change.
Comment 2 Jaroslav Tulach 2011-08-25 11:14:14 UTC
Y01 Don't use subclassing, use composition: create a factory method which takes something and returns JPDABreakpoint. Leave the class final.

Y02 I don't understand the usecase, but setSession clearly serves two purposes: Is any client supposed to call it? Why? Is any subclass supposed to override it? Why?

Y03 fireJPDABreakpointChange is not final.

Y04 protected static methods are quite useless - e.g. anyone can call them. The purpose of fillFilesForClass remains an undocumented mistery...

Y05 There is tons of other (untouched by the patch) methods in the JPDABreakpoint where one should decide what purpose they serve. So far they were good only for callers, now, when the class is not final, do they serve double purpose? That would not be a good sign.



Btw. in case you implement Y01, the Y02-Y05 will be automatically rendered obsolete.
Comment 3 Martin Entlicher 2011-08-29 13:05:56 UTC
Y01 Changing subclassing to composition would go against the current principle, since Breakpoint is an abstract class and all it's implementation classes are subclasses of Breakpoint. Therefore to allow subclassing of JPDABreakpoint sounds natural to me.

However I've managed to implement the component breakpoints without the necessity to extend JPDABreakpoint, therefore I'm closing this issue as won't fix.
Thanks for your comments.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo