On Thu, Jun 22, 2000 at 10:46:05AM -0400, Stuart Ballard wrote:
> Jochen Hoenicke wrote:
> >
> > Okay, I can do that, but is org.gnu.java.util.collections a good
> > package name? Or do you prefer something like
> > gnu.classpath.collections?
>
> Speaking for myself only, I'd suggest putting it in com.sun. I know that
> it sucks to be writing code in Sun's package domain, but this would let
> us be a drop-in replacement for Sun's code. Especially for binary-only
> programs that assume it will be in com.sun...
>
> Thoughts?
I would like them to be just in java.util where they are now.
This shows that you can easily use (finished) parts of Classpath now.
And it would indeed really suck to write packages for com.sun.
The reasons not to do this are:
- Not all VMs/Classloaders allow adding to java.* packages
(And for security reasons that might be a very good thing.)
- Some binary only programs expect them to be in com.sun.
(But do we really care about binary only programs?)
So if you are really up for a challenge then you could try to
generalize your perl script to turn it into a generic
package migration tool that dynamically changes classes
so they appear in different packages but you have to
be carefull to change all fully qualified package names and
change the package and import staements.
That way you could add a configure option for the actual package
--collection-package=some.random.package
This could of course be done in the Java Source or the Java Bytecode.
And someone could also try to write a classloader that does this kind
of thing on the fly :)
I would love to write some of that.
(I really would like to have a flexible package migration tool!)
I have absolutely no time right now.
But I would like to see the script that you use now.
I also hoped that I would have some time to integrate the
java.util.zip package from libgcj but I now know that I will
not be able to do any work on it until the first of July.
So if someone wants to have a try please do.
Cheers,
Mark
