Geir Magnusson Jr wrote: > > > Tim Ellison wrote: > >> >> The problem is that once you release a module with a particular internal >> API into the wild you need to ensure that other modules that depend upon >> it are not broken by your internal API changes. > > But aren't they internal?
I'm confusing things ;-) There are two 'internals'. Internal to a specific module's implementation (org.apache.harmony.internal.*) and internal to Harmony i.e. not part of the Java-spec but a useful utility to share with other modules. These are the two categories in Anton's original note. A module can mess with it's internals as much as it pleases; but the utilities it shares with other module's should be managed. Regards, Tim >> In general, unless you >> control the make-up of the runtime you will not know whether you are >> breaking other modules (or to put it another way, you can check that you >> don't break other modules for a given build but other people may be >> combining different versions of the modules). With runtime support you >> can have multiple versions of a module simultaneously, without runtime >> support you must retain binary compatibility. In practice this simply >> means knowing which changes are allowed, and which require a new >> internal API. >> >> Regards, >> Tim >> >>> On 2/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >>>> I've put a first cut of the proposed package naming convention on the >>>> website: >>>> >>>> http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html >>>> >>>> >>>> Regards, >>>> Tim >>>> >>>> Leo Simons wrote: >>>>> On Fri, Feb 10, 2006 at 12:52:09PM +0300, Anton Avtamonov wrote: >>>>>>> As I wrote elsewhere, I propose that packages whose naming >>>>>>> convention is: >>>>>>> org.apache.harmony.<modulename>.<something> >>>>>>> >>>>>>> represent internal APIs. All visible (public/protected) types in >>>>>>> those >>>>>>> packages can be used by class library developers from any module, >>>>>>> and >>>>>>> such developers can expect the API to be evolved in a compatible >>>>>>> way. >>>>>>> >>>>>>> Module developers should not rely on the stability of anything >>>>>>> starting: >>>>>>> org.apache.harmony.<modulename>.internal >>>>>>> >>>>>>> and are strongly discouraged from referencing visible types in such >>>>>>> packages since these are type internal module implementation code >>>>>>> (and >>>>>>> when we turn on OSGi runtime checks the imports from other >>>>>>> modules will >>>>>>> fail). >>>>>>> >>>>>>>> From other hand if we are talking about using these useful >>>>>>>> classes only >>>>>>>> inside Harmony then it's probably a good idea. But we need some >>>>>>>> procedure >>>>>>>> for moving a class to utilities package and we need to notify >>>>>>>> developers >>>>>>>> about class capabilities. >>>>>>> Moving it to a 'utilities' package should be as simple as making >>>>>>> it a >>>>>>> non-internal package name; and the notification is javadoc of those >>>>>>> non-internal types. >>>>>>> >>>>>>> If people agree I'll write something for the website along these >>>>>>> lines, >>>>>>> if not we can continue to debate it on the list. >>>>> +1 (to the website thing, though debate obviously is fine too :-D). >>>>> >>>>> I personally think that it is a good idea to seperate out >>>>> non-J2SE-specific >>>>> non-Harmony-specific stuff as much as possible. I also think it is >>>>> a good idea >>>>> to evaluate very carefully on a case-by-case basis whether it makes >>>>> sense to >>>>> have that kind of code live under the "harmony" banner -- >>>>> experience has shown >>>>> that breaking out "true" utility stuff can help result in wider >>>>> usage of that >>>>> stuff which tends to result in more bugfixes, better code, etc. >>>>> >>>>> For example (and I'm being really naive here) I can imagine that >>>>> java.util >>>>> could be built on top of jakarta-commons-collections, or that >>>>> java.util.logging >>>>> could be built on top of log4j (now that'd be cool). >>>>> >>>>> But this is just me imagining stuff that might be possible in the >>>>> future. For >>>>> now it doesn't make sense to worry or think about this too much - >>>>> we'll see >>>>> what kind of ties between harmony and something like >>>>> jakarta-commons (or >>>>> whatever other part of the open source java space we're on about >>>>> here) is >>>>> possible as the issue comes up. >>>>> >>>>> cheers! >>>>> >>>>> Leo >>>>> >>>>> >>>> -- >>>> >>>> Tim Ellison ([EMAIL PROTECTED]) >>>> IBM Java technology centre, UK. >>>> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
