I was looking into the javax.naming issue against 1.3 (field CompoundName.impl missing in classpath) and found that (unsurprisingly) the author of the class was completely aware of the "missing" impl field but there was no good solution, because the impl field is of type javax.naming.NameImpl which is a package-private class.
It would of course be easy to "solve" the API problem by defining our own empty package-private NameImpl class, but I'm wondering if it would be better for Japitools to catch this kind of situation and treat the "impl" field as if it's package-private itself - that is, ignore it entirely since japi only deals with public and protected members. I can't think of any reasons why any such field (or a method taking a non-public type as a parameter or returning one) should ever matter in practice for compatibility, but I'd like to see if other people feel the same way before trying to implement skipping them. I'm already doubting the last decision I made in japitools without feedback (I'll post about that separately) so I'm being cautious :) The only problem with such an approach is that it would probably slow down japize and increase its resource usage somewhat (no idea yet exactly how much, could be minor but could easily be dramatic), because currently the types of fields, return types of methods and parameter types of methods and constructors are just referenced by name in japize - the corresponding classes are never actually loaded from the zip (or rather, they're only loaded when it's time to process *that* class, not when it's referenced from somewhere else). But loading them is necessary to determine what their modifers are to decide whether to skip them. Stuart. -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
