Talk:FriendPackages

From APIDesign

Comments by Tim Band (TBa).

• TBa: Accessor could perhaps be called ItemAccessor (living in ItemAccessor.java)? This makes it more obvious that you have to write this boilerplate for each class needing the back door. TBa
• JST: Actually once per package is enough.

• TBa: It would be nice to be able to put in extra comments without cluttering up the text. Hovers would be ideal, but I guess not supported by this Wiki (and not in the code section anyway). Is there any way of doing footnotes?
• JST: This is wikipedia::mediawiki and it has a lot of extensions. More than I know about.

• TBa: The particular point is the line l = listener in Item.java. This is presumably so that in the presence of multiple threads, an "obsolete" listener may be called, but you will never get a null pointer exception. That's too much to clutter the code with, but it spent quite a bit of my effort working it out.
• JST: The current code is not really multithreaded. As far as the initialization goes, it shall not matter, as it is expected that the setDefault method is part of implementation not API and as such it will be called just once.

• TBa: Should all the "default"s really be called "default"? aren't we really talking about TheAccessor or something?
• JST: I am not sure I get the comment, but NetBeans usually call singleton returning methods getDefault(). Having symmetrical setDefault(...) is appropriate, I guess.

• TBa: It is much clearer setting the DEFAULT directly than the book's indirect classloader method, but now shouldn't setDefault be synchronized?
• JST: The classloading trick is still there, I just moved it outside of the code snippets. It is only necessary if someone uses Accessor first without Item being loaded (e.g. which is only possible while calling constructor, I guess):

Code from Accessor.java:

private static final Class<?> INIT_API_CLASS = loadClass(
    Item.class.getName()
);
private static Class<?> loadClass(String name) {
    try {
        return Class.forName(
            name, true, Accessor.class.getClassLoader()
        );
    } catch (Exception ex) {
        throw new RuntimeException(ex);
    }
}
 

• 'JST': It might be possible to to put a guard in constructor of Accessor just like in this example:

Code from InterfaceThatJustJoeCanImplement.java:

public abstract class InterfaceThatJustJoeCanImplement {
    protected InterfaceThatJustJoeCanImplement() {
        if (!"impl.joe.JoesImpl".equals(getClass().getName())) {
            throw new IllegalStateException(
                "Sorry, you are not allowed to implement this class"
            );
        }
    }
 
    public abstract void everyoneCallThisJoeWillHandleTheRequest();
}