This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 36924 - Do not break compatibility of TopComponent
Summary: Do not break compatibility of TopComponent
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: mslama
Depends on:
Blocks: 36122
  Show dependency tree
Reported: 2003-10-30 08:14 UTC by Jaroslav Tulach
Modified: 2008-12-22 16:05 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Introduces TopComponent.ID - caching of unique ID has to be done in WM, but that should be ok, I guess (3.17 KB, patch)
2003-10-30 08:33 UTC, Jaroslav Tulach
Details | Diff
Diff of patch (2.44 KB, patch)
2003-11-04 10:02 UTC, mslama
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2003-10-30 08:14:46 UTC
Do not break binary compatibility of TopComponent
subclasses by introducing new final methods, it
would be nice to keep source compatibility, but
that is not such a strong requirement.

That is why it was agreed that there should be no 

public final String getId ();

and that this method should be moved into
WindowManager, where it logically belongs as
WindowManager is the final decision maker as
concern the actual id of the component:

public abstract String WindowManager getId

It has however been decided that it is ok to keep the

protected String TopComponent.preferredId ();

that will be used by the window manager when
computing the getId value. The possible source
compatibility problems were found acceptable in
this case.
Comment 1 Jaroslav Tulach 2003-10-30 08:20:23 UTC
My own opinion: I was thinking about the problem a bit and I'd like to
suggest another solution, which would address the discoverability of
the getId method (hidden in previous suggestion among other methods in
WindowManager). The good think on this solution is that it does not
introduce binary or source compatibility problems and also keeps the
getId method in TopComponent. 

I'd like other reviewers to review attached patch. If not agreed, then
just ignore it and implement the one described in previous chapter.
Comment 2 Jaroslav Tulach 2003-10-30 08:33:37 UTC
Created attachment 12017 [details]
Introduces TopComponent.ID - caching of unique ID has to be done in WM, but that should be ok, I guess
Comment 3 Jesse Glick 2003-10-30 15:58:21 UTC
Not sure that's much of an improvement. (BTW tc.getID().getID() is ugly.)

If discoverability of the getID method is the main problem, consider
simply renaming it to e.g. getPersistenceId() (with corresponding
preferredPersistenceId()) and making it final in TC as before the TCR
- unlikely to be a name conflict with an existing subclass.

No strong feelings here though - either the solution initially
described in this issue, or Yarda's new patch, would be OK.
Comment 4 Peter Zavadsky 2003-10-31 09:36:59 UTC
My opinion is that tc.getID().getID() shouldn't be used. I think it
should be much more important that the API is clear and understandable.
Comment 5 mslama 2003-11-04 08:16:53 UTC
I am going to implement solution with 
public abstract String WindowManager.getTopComponentId(TopComponent) and 
protected String TopComponent.preferredId()
Comment 6 mslama 2003-11-04 10:03:00 UTC
Created attachment 12052 [details]
Diff of patch
Comment 7 mslama 2003-11-04 10:07:02 UTC
Please check last diff. If there will be no objections I will commit
it tomorrow.
Comment 8 mslama 2003-11-04 12:44:20 UTC
Jarda suggests findTopComponentID instead of getTopComponentID due to
some consistency with other WindowManager public methods.
Comment 9 mslama 2003-11-04 12:49:45 UTC
Fixed in winsys branch.
Comment 10 Jaroslav Tulach 2003-11-04 15:18:20 UTC
Comment 11 Jesse Glick 2003-11-05 08:36:42 UTC
Can WindowManager.getTopComponentID be final, if topComponentID is
doing the actual work anyway?

Otherwise, fine.