Bug 572392 - Erroneous Window.getShell code/Javadoc
Summary: Erroneous Window.getShell code/Javadoc
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: IDE (show other bugs)
Version: 4.19   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 572391
  Show dependency tree
 
Reported: 2021-03-29 04:07 EDT by Ed Willink CLA
Modified: 2021-03-30 06:01 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2021-03-29 04:07:56 EDT
Window.getShell() is JavaDoced as

	 * @return this window's shell, or <code>null</code> if this window's
	 *         shell has not been created yet


But Window.close assigns shell to null.

Surely the assignment is wrong; the Javadoc is correct so that users can use shell.isDisposed() to detect creatred but no longer live.
Comment 1 Wim Jongman CLA 2021-03-29 09:36:59 EDT
(In reply to Ed Willink from comment #0)
> Window.getShell() is JavaDoced as
> 
> 	 * @return this window's shell, or <code>null</code> if this window's
> 	 *         shell has not been created yet
> 
> 
> But Window.close assigns shell to null.
> 
> Surely the assignment is wrong; the Javadoc is correct so that users can use
> shell.isDisposed() to detect creatred but no longer live.

You are right. Please supply a patch. This is one of the things that could have been fixed in one minute if we had our code hosted on GitHub.
Comment 2 Ed Willink CLA 2021-03-29 14:56:46 EDT
(In reply to Wim Jongman from comment #1)
> You are right. Please supply a patch. This is one of the things that could
> have been fixed in one minute if we had our code hosted on GitHub.

Maybe. I doubt that even you can do it in under 5 minutes and more like an hour or two once you have run tests. I don't see that GitHub would save me any time since I have to clone the repo(s).

For me, it will take at least an hour and probably over half a day to setup to delete one line of code.

Regardless. I expected a wontfix-legacy-issues response, since the GIT history must be studied to see whether the null assignment was always there or crept in under maintenance. Whatever. The semantic change must be assessed by an experienced committer. No point me doing it since I don't understand the issues.
Comment 3 Wim Jongman CLA 2021-03-29 15:02:30 EDT
(In reply to Ed Willink from comment #2)

I just think we need to update the javadoc:

 * @return this window's shell, or <code>null</code> if this window's
 *         shell has not been created yet or if the window has been closed
Comment 4 Ed Willink CLA 2021-03-29 15:11:38 EDT
Is is certainly the least-breaking solution, but the history of the null assignment should be determined to see if the null assignment is actually a very recent breakage that should be reversed.

For my own purposes my code has to be compatible with all platform versions from Oxygen onwards and so for 2021-03 must accommodate a null return.
Comment 5 Rolf Theunissen CLA 2021-03-30 02:41:55 EDT
From the documentation on the Window class:

 * <p>
 * Opening the window will create its shell and widget tree if they have not
 * already been created. When the window is closed, the shell and widget tree
 * are disposed of and are no longer referenced, and the window is automatically
 * removed from its window manager. A window may be reopened.
 * </p>

Furthermore, the null assignment is there as long as the file exists, i.e., it is there in the 'First cut of org.eclipse.ui split' commit on the file 19 years ago.
Comment 6 Ed Willink CLA 2021-03-30 06:01:37 EDT
Agreed fix the Window.getShell() Javadoc.