z-man wrote on 21.04.2007 09:47:

Although I don't think there is a license issue, I would still try to avoid this
for reasons of documentation.

If someone else joins your team or needs to extend your work, this naming
convention could be very irritating. If I see a class that is located in
java.lang I expect to find the documentation in the JDK API but in your project
I wouldn't

Thomas

I haven't read their newer licenses, but that was the core of Sun's lawsuit
against Microsoft. MS had added classes (or methods, I forget which) in the
java.* package which were in fact unique to MS's own JVM. Clearly the intent
was to deceive developers into unknowningly writing Windows-only Java apps,
undermining its cross-platform promise.

Having said that, there's a *huge* difference between adding a java.* class
to your app, and adding one to your own JVM. I think Sun's license would
really only be relevant if you were doing to latter, and if you wanted to
refer to it by the trademarked name "Java".

For the record, I am not a lawyer.

sherm--

Section 6.8.1 of the JLS (3rd edition) states that package names starting
with 'java' are reserved by Sun.

(See
http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.8.1 )

It used to be the case that there was a developers note on the java* and
sun* packages that explained the rationale for developers not writing new
code in those packages. I can't seem to find it now, but it was there ages
ago.

I believe the license on Java VMs (used to, anyway) forbid adding classes to
those packages.

I've heard (but not verified) that the Sun VMs have special-case handling
for classes that live the java* packages, particularly java.lang. Because of
that special handling, you might get unexpected behavior.

Might I suggest using 'java.lang.UnsupportedOperationException' instead of
your custom 'NotImplementedException'? (Generally, a developer ought to be
throwing exceptions that are already defined in the libraries instead of
writing their own -- when the exception makes sense!)

-- Adam Maass

In general I would consider it bad practice to hijack others packages,
because it gives the impression that somebody else is responsible.

java. and javax. for the public API's - all other uses reverse
internet domains - that is the prescribed naming convention.

Within your reverse internet domain you are free to choose whetever
package structure you prefer.

Arne

Extending other people's packages is almost always wrong. In the case
of java packages, it is double wrong.

It is wrong to extend other people's packages because the default
package protection mechanism can fail (two classes in the same package
can not see each others package private variables and methods). The
reason is that these classes are loaded by different classloaders.
Because you have different class loaders loading the same package, you
also easily get shadowing of classes with the same name.

Extending java.lang is doubly bad, but also likely to be impossible.
Common classloading rules first look in the parent classloader. The
loader that loads java.lang is at the top and therefore gets the first
try. It is possible to seal packages, which means that only one
classloader may provide a package.

The OSGi specifications, a dynamic module system for Java
(www.osgi.org), the rule is therefore to always delegate java classes
to the parent.

Classloading is a complicated and messy business. Please do not muck
around with it if you want your code to run. If you do, it is likely
the legal aspects are your small problem over time. One of the great
inventions of Java is the global namespace that is used. Mucking with
other people's packages violates a lot of assumptions and will bite
you.

Kind regards,

   Peter Kriens

In addition to all that has been said here, summarized by 'don't', if
your code ever runs under a security manager it will throw an exception
because defining classes in the java.* or sun.* packages requires a
permission.