A package java-common is created, containing this policy.
Two virtual packages are created, java-compiler and java-virtual-machine.
Java compilers must provide java-compiler and depends on java-common. They should use /etc/alternatives for the name 'javac' if they are more or less command-line compatible with Sun's JDK javac. They should have a CLASSPATH predefined which includes /usr/share/java/repository.
Java virtual machines must provide java-virtual-machine and depends on java-common and use /etc/alternatives for the name 'java'. They should have a CLASSPATH predefined which includes /usr/share/java/repository.
The problem of Java core classes is put on hold. In the mean time, Java virtual machines are requested to come with their own core classes. (Or to depends on another VM, like jikes does.)
If a given source (like the JDK does) brings both a compiler and a virtual machine, you MAY name the compiler package xxxx-dev.
Packages written in Java are separated in two categories: programs and libraries. Programs are intended to be run by end-users. Libraries are intended to help programs to run and to be used by developers. Both must depend on java-virtual-machine.
Both are shipped as Java bytecode (*.class files, may be packaged in a *.jar archive) and with an "Architecture: all" since Java bytecode is supposed to be portable.
Programs must have executable(s) in /usr/bin and be executable. They can be Java classes (using binfmt_java, in Debian <= 2.1 or binfmt_misc, in Debian > 2.1) or wrappers. In any case, they must run without specific environment variables (see Policy 3.8), for instance CLASSPATH. They must respect the Policy rules for executables (for instance a manual page per executable, see Policy 6.1). If they have their own auxiliary classes, they MUST be either in a .jar in /usr/share/java/PACKAGE-NAME.jar or use the General Java Repository described below. Programs must depend on java-virtual-machine.
Libraries are not separated between developers (-dev) and users versions, since it is meaningless in Java. Their classes MUST be either:
in a .jar archive in /usr/share/java/PACKAGE-NAME.jar
or in the General Java Repository.
In the first case, they must have a well-documented CLASSPATH, so that developers should know what to add to their wrappers.
This applies only to libraries, not to the core classes.
A General Java Repository is created by java-common in /usr/share/java/repository. Classes which comply with the hierarchical packages naming (for instance, gnu.getopt, com.foo.bar), may install classes under it. It is expected that adding /usr/share/java/repository to the CLASSPATH is enough to run any Java program which depends on such classes (this should be done by Java virtual machines or compilers).
This policy does not address the issue of documentation (for instance HTML pages made with javadoc).
There is no naming rules for programs, they are ordinary programs, from the user point of view. Libraries packages must be named lib-XXX-java.
About politics: packaging Java stuff changes nothing to the rules Debian uses to find if a program is free or not. Since there are not many free Java tools, keep in mind the following:
If you source package can compile (correctly) only with non-free tools (the only free Java compilers seems to be guavac and gcj and may be jikes if it changes its licence), it cannot go to main. If your package itself is free, it must goes to contrib.
If your binary package can run only with non-free virtual machines (the only free Java virtual machine seems to be kaffe - and the one included in libgcj), it cannot go to main. If your package itself is free, it must goes to contrib.