Community
Participate
Working Groups
I was helping someone on IRC last week with some SWT problems when I realized he had extended Shell. He claimed to not get any exceptions (via checkSubclass(), though I find that hard to believe). While confirming the code within checkSubclass(), I noticed that Shell does not have the @noextend API tag. From skimming around bug 261391, it seems it was just forgotten, is this correct? I noticed it says... IMPORTANT: This class is not intended to be subclassed. ...instead of... IMPORTANT: This class is <em>not</em> intended to be subclassed. ...which might explain why Carolyn missed it in her search?
Thanks, Remy. Yes, it looks like I missed that one, and yes, checkSubclass() should have given a "Subclassing not allowed" SWTException for Shell. I'll mark this for 3.6 and put it in early in the 3.6 cycle.
Oops - moving to 3.7.
Fixed > 20110516 for 3.7RC2.
Marking Fixed.
Carolyn, could you please set an API baseline (3.6.2) and then use the quick fix to add an API filter for the API change on Shell? Olivier, I guess this also needs to be added to the API freeze exclusion list.
Add these lines at the end of your .api_filters file: <resource path="Eclipse SWT/win32/org/eclipse/swt/widgets/Shell.java" type="org.eclipse.swt.widgets.Shell"> <filter id="336744520"> <message_arguments> <message_argument value="org.eclipse.swt.widgets.Shell"/> </message_arguments> </filter> </resource> You might also need the same filter for all platforms. This will work for win32.
(In reply to comment #5) > Olivier, I guess this also needs to be added to the API freeze exclusion list. I will add it once I get the error reported in the API freeze report. This is the easiest way to run the tool and get the new exclusion.
Olivier, can you come and work with me on this? We do not have a separate .api_filters file for each platform. I don't think the api filtering is set up to work with something multi-platform like swt. Our current file seems to be cocoa-based. There used to be win32 stuff in previous versions of the file, but someone must have released changes under cocoa, or maybe there is some other reason for this. Maybe we need one big file that filters all platforms. I will need help in constructing this file, or in figuring out an alternate solution. Thanks.
I cannot get to this today - I have to leave now. Is tomorrow too late for .api_filters changes to go in for RC2?
(In reply to comment #9) > I cannot get to this today - I have to leave now. Is tomorrow too late for > .api_filters changes to go in for RC2? It depends on whether a rebuild will be requested (Thursday 08:00 EDT is the last official RC2 build).
Thanks, Dani. Apparently, we are requesting a rebuild for a different problem, so I will piggyback on that. :) Olivier, I see why we have all cocoa and no other platforms in our current .api_filters (someone who was working on cocoa accidentally released the .api_filters file). Before that, we only had win32 filters. I don't understand why there aren't any win32 errors when I am on win32? There was only the one Shell error - which I fixed with quick fix. (Also, why did quick fix specify standalone="no" ? Should I release that change?) Still need help, please.
Fixed > 20110519. Change in .api_filters is the same as in comment 6 (plus standalone="no"). Changed org.eclipse.pde.api.tools.prefs to ignore unused problem filters because we have a lot of them. We will let the cocoa changes go through. The reason there aren't a ton of win32 errors is that the api baseline has changed and the win32 api filters were already released long ago and saved in an .api_baseline file that is part of the project metadata. Apparently, we are supposed to delete the .api_filters file every year after the release and start fresh. I will open a bug to do this.
