Jan Evert van Grootheest <[EMAIL PROTECTED]> writes: > 1. why is there a difference between java1 and java2? Isn't java1 > virtually obsolete?
"Debian Will Remain 100% Free Software" As long as there are no free implementations of java2 we can't let java1 slip into obsolescence. > 2. why must java-compiler depend on java-runtime???? I propose to make > this a suggestion. For example, gcj isn't a java class. Perhaps a > note to enlighten naive readers like me? A Java compiler needs the Java system classes to compile anything useful, just as a C compiler needs the C library's headers. > 3. I don't understand why 'auxliary classes' (section 2.3) must follow > the naming for libraries. I don't think this requirement makes much sense: either these classes are useful to other packages (in which case they really form a library, and should be packaged as such), or they are only for this package's use: then they could either go into the main jar, or into other jar(s) with specific naming (but not necessarily libXXXX.jar). > I can image that the name often is > determined upstream. Sure, but we could change the names (not that I'm sure that we always want to). It will surely be necessary to disambiguate stupid names like "util.jar". > 4. what about JNI? As you note in the heading of chapter 2, java > bytecode is portable. But packages may contain JNI. These should be treated mostly like VMs, I think. > 5. what about j2ee? I propose to further make difference between > java1, j2se, j2ee and j2me? I think we must be prepared for at > least the ee version to be packaged. > > 6. How to handle apis? things like jaxp, jndi ext. These may be > available as separate libraries or included in a runtime (see Suns > JDK 1.4). Do we (and where) determine virtual packages for those? I think these should get in when a specific need arises. There's not much point in overengineering this part with virtual packages when we only have one alternative providing them anyway. -- Robbe
signature.ng
Description: PGP signature
