directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: Coding Standards: API, IMPL and reuse
Date Tue, 21 Sep 2004 19:58:48 GMT
On Wednesday 22 September 2004 02:32, Noel J. Bergman wrote:

> This issue came up in terms of exposing other people's packages in our API.
> So are you suggesting that since J2SE APIs are not clean, where clean is
> defined as a total API/impl separation, that we not expose them in our
> public API?

The JDK classes are not an issue, whether they are clean or not is irrelevant, 
they sit in the bootstrap classloader and can't be exchanged during the 
life-time of the JVM. 

Since you don't care about classloading and/or think that it is not an issue 
and/or an issue for someone else, then isn't this discussion meaningless. If 
no reloading or hot-deploy is ever going to occur, just throw everything into 
the system classloader and ignore dynamicity, which is what most people think 
is appropriate.

Conclusion (the point where think stops) is that a lot of this debate is 
around terminology. What is API vs Impl? After discussing the same issue with 
Log4J, it seems that API for most people is a "blob" that does something 
according to a set of documentation. If that is the definition, then you are 
not designing for hot-swap and dynamic systems, and a system that do 
understand the difference will treat your "API" as an implementation "blob", 
together with all the code that links to it.
Whether or not the packaging can be changed later to deal with what I am 
talking about, depends a lot on how the API is designed and what is exposed 
in the methods. Furthermore, people are people and makes mistakes. It is not 
uncommon that dependencies from API to Impl classes are introduced by mistake 
or "couldn't figure it out", which is not the case when they are separated in 
the build system, since a cyclic dependency will result.

  /        /
 / / 

View raw message