Greetings, I was revisiting our deprecated API usage in JSF tools this morning and it occurred to me to ask what work is planned in 3.1 to fix the problem that currently exists with deprecated API. I'm mainly interested in the SSE and related API, although there may be others.
I will open a new bug if there isn't one existing, but here are three deprecation quandries we have as examples: 1) IStructuredModel.getResolver(). This was deprecated with no clear migration path. I think this is probably because the IURIResolver that it returns is also deprecated. However, there is no new API to get the new URIResolver. AbstractStructuredModel still uses the deprecated one. Even more confusingly, there is also a setResolver() that is public, not marked non-API and not deprecated. 2) StructuredTextEditor.getModel(). Based on comments in the source, this method has been considered problematic at least as far back as 2002. There is a note on the deprecation (making it a bit better than getResolver) that recommends an alternative, however, the getter changes internal private state on StructuredTextEditor so it is unclear if it is safe to follow the path. 3) More minor are methods on the IDOMNode hierarchy of interfaces. For example, IDOMNode has getNameRegion, which is reasonably deprecated, but only because it should be moved to only IDOMElement sub-classes. Deprecations are also inconsistent. For example, IDOMDocument.isXMLType() is deprecated, but IDOMAttr.isXMLAttr is not. I believe there are a lot of non-breaking (or very limited breakage) API changes that could be made without a lot of effort that hugely improve confidence for adopters. Thanks, Cameron _______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
