Extending the standard packages: is it legal?

[z-man]

Hello all,

skimmin' through many Java open source code bases, I noticed that it
seems to be an established policy to put ancillary (utility) classes in
packages like %projectRootPackage%.util, despite often being just
extensions of standard packages (e.g.: a general-purpose custom
collection class).

Now I face a similar situation: I've implemented a general-purpose
exception class (mypackageroot.lang.NotImplementedException) that just
covers a generic functionality that I would have expected to be inside
the standard platform: I feel it would be MUCH more elegant to place it
under its "natural" location (java.lang package), because relating it
strictly to my package root seems to insert an alien within my project
space.

So, is there any argument against my perception?
At the bottom line, is it contractually legal to extend the standard
J2SE packages with custom classes? May I incur into license violations
with Sun?

Thank you

 

[Thomas Kellerer]

z-man wrote on 21.04.2007 09:47:

Now I face a similar situation: I've implemented a general-purpose
exception class (mypackageroot.lang.NotImplementedException) that just
covers a generic functionality that I would have expected to be inside
the standard platform: I feel it would be MUCH more elegant to place it
under its "natural" location (java.lang package), because relating it
strictly to my package root seems to insert an alien within my project
space.

So, is there any argument against my perception?
At the bottom line, is it contractually legal to extend the standard
J2SE packages with custom classes? May I incur into license violations
with Sun?

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

 

[Sherm Pendley]

At the bottom line, is it contractually legal to extend the standard
J2SE packages with custom classes? May I incur into license violations
with Sun?

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--

 

[Adam Maass]

Hello all,

skimmin' through many Java open source code bases, I noticed that it
seems to be an established policy to put ancillary (utility) classes in
packages like %projectRootPackage%.util, despite often being just
extensions of standard packages (e.g.: a general-purpose custom
collection class).

Now I face a similar situation: I've implemented a general-purpose
exception class (mypackageroot.lang.NotImplementedException) that just
covers a generic functionality that I would have expected to be inside
the standard platform: I feel it would be MUCH more elegant to place it
under its "natural" location (java.lang package), because relating it
strictly to my package root seems to insert an alien within my project
space.

So, is there any argument against my perception?
At the bottom line, is it contractually legal to extend the standard
J2SE packages with custom classes? May I incur into license violations
with Sun?

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

 

[Lew]

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 ) ....
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!)

It also both stupid and unnecessary to add to java[x].*. You can extend, say,
Exception just fine in your own domain, no need to pretend to be in Sun's.

The stupid part is that to add to java[x].* is to declare that your code is
part of the Java language itself, which is anything but "natural". It would
render your code unusable outside your private world.

Are you really thinking that your class is part of the whole language? It
seems much more "natural" to think of your /custom/ class as part of /your/
package than Java's, eh? At least, that's how it would seem to a Java programmer.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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.

As I recall it then it was more the missing parts than the extra
parts that got them in problems.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

skimmin' through many Java open source code bases, I noticed that it
seems to be an established policy to put ancillary (utility) classes in
packages like %projectRootPackage%.util, despite often being just
extensions of standard packages (e.g.: a general-purpose custom
collection class).

Now I face a similar situation: I've implemented a general-purpose
exception class (mypackageroot.lang.NotImplementedException) that just
covers a generic functionality that I would have expected to be inside
the standard platform: I feel it would be MUCH more elegant to place it
under its "natural" location (java.lang package), because relating it
strictly to my package root seems to insert an alien within my project
space.

So, is there any argument against my perception?
At the bottom line, is it contractually legal to extend the standard
J2SE packages with custom classes? May I incur into license violations
with Sun?

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

 

[Richard Senior]

The stupid part is that to add to java[x].* is to declare that your code
is part of the Java language itself, which is anything but "natural".
It would render your code unusable outside your private world.

Exactly. What happens if Sun decide to create a NotSupportedException?
They are perfectly entitled to do that and your program breaks. The
whole point of the namespace convention based on reverse domain name is
to avoid such conflicts.

Richard

 

[Bent C Dalager]

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.

As I remember, this wasn't a license issue but a contract issue:
Microsoft had sigend a contract with Sun where they said they wouldn't
do this and then they did anyway.

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".

I would think the license says something explicit about not being
allowed to redistribute an altered VM.

Cheers
Bent D

 

[pkriens]

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

 

[Esmond Pitt]

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.

 

[Tom Hawtin]

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.

You can't even define a class in java.* if you have all the permission
in the world (well, okay you may be able to use, say, reflection to hack
around it). The check for java. is in ClassLoader, and it doesn't check
for a security manager. You would have to run the JVM with -Xbootclasspath.

sun.* (and couple com.sun subpackage in Java WebStart/PlugIn) are
restricted with the package.access security property.

Tom Hawtin