Re: Java Project API/SPI

Jan Pokorsky wrote:
> Java Project API refinements:
> 
> In order to make the api classes less overcrowded with methods and to 
> prevent future compatibility issues I would propose to split following 
> classes to API and SPI part:
> 
> 1. ProjectPath:
> http://www.netbeans.org/download/prj40_prototype/javadoc/JavaProjectAPI/org/netbeans/api/java/project/ProjectPath.html 
> 
>   API: the class should be final. Just static methods would remain.
>   SPI: introduce
> public abstract class AbstractProjectPath {
>   public abstract PathResource handleCreateResource(FileObject filebase)
>        throws IOException;
>   public abstract ClassPath getPath(ProjectMember object, Object type);
> }

What is the "handleCreateResource" method for ? It is not obvious from 
the javadoc at all; shouldn't be the fact, that PathResources are based 
on FileObjects (indirectly through ProjectMembers) or included in some 
fixed sets of Classpaths an implementation detail of each provider ?

> 
> 2. JavaProject:
> http://www.netbeans.org/download/prj40_prototype/javadoc/JavaProjectAPI/org/netbeans/api/java/project/JavaProject.html 
> 
> 
>   API: the class should be final. Remove needless support methods like 
> fireXXX, listenerAttached.
>   SPI: introduce public abstract class BasicJavaProject containing all 
> support methods and those neccessary for proper functionality of the 
> api.JavaProject.
> 
What is the advantage of this design over implementing directly the API 
method by the provider ? Is the number of abstract methods (the methods, 
which in fact define the project's functionality) small enough so that 
richer final API class can be built around a small set of SPI methods ?

-Svata