Tim Ellison wrote:
Geir Magnusson Jr wrote:
I don't like "tests" for obvious reasons that we've discussed before.
remind me
package visibility
I do like "examples" as that's clear to people.
"internal" is interesting, because we already have mechanisms in Java to
do this, so I don't see the point.
huh? what?
It's also really unnatural to me to
do this in a package scheme. I wish I could be clearer on why this
sets my teeth on edge, but I can't, so I'll think about it a bit more...
just so we understand one another...
- our end users may use:
java.<whatever> and friends (as defined by spec.) from
any module
Sure
- developers of a given module may use:
java.<whatever> and friends from any module
org.apache.harmony.* (but not 'internal') from any module
org.apache.harmony.internal.* from this module
I see - so you can have public o.a.h.<woogie>.i.Foo that no one should
touch except for <woogie> classes...
geir
This 'visibility of packages' is not part of the Java language.
Regards,
Tim
Tim Ellison 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
