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

Summary:	Do not break compatibility of TopComponent
Product:	platform	Reporter:	Jaroslav Tulach <jtulach>
Component:	Window System	Assignee:	mslama <mslama>
Status:	VERIFIED FIXED
Severity:	blocker	CC:	jglick, pbuzek, pzavadsky, tpavek
Priority:	P1
Version:	3.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Bug Depends on:
Bug Blocks:	36122
Attachments:	Introduces TopComponent.ID - caching of unique ID has to be done in WM, but that should be ok, I guess Diff of patch

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
(TopComponent);

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

Ok.

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.