On Sat, 2005-06-04 at 12:02 -0700, Casey Marshall wrote: > Hi, > > I've started work on bringing Classpath's JSSE API (javax.net[.ssl]) up > to 1.5-level coverage, and the natural snag in doing this in mainline is > that it uses new language features -- two enums. It's easy enough to > write these two classes as pseudo-enums, but I was curious if there was > enough interest in making a PseudoEnum class that can be used by other > parts of the API. I'm not sure, but I think it should be possible to > make a mostly-binary-compatible enum class for pre-1.5 Java, but > wouldn't mind some advice if someone is more familiar with this. >
There is already working enum support (with a suitable compiler) available on the generics branch of Classpath. Thus, the general consensus on 1.5 extensions that need 1.5 language features (generics, annotations and enums primarily -- the rest are syntactic shortcuts) is to add this code to the generics branch. I've recently been using this as my primary development environment (ecj+jamvm 1.3+classpath-generics) and haven't experienced any major problems. We can't add enums to HEAD until there is more widespread support, primarily in the compiler realm (VM support is largely reflection-based; the binaries are compatible with the new data being stored in optional sections). I can see your reasoning for a pseudo-enum class but I would only think it necessary to add something to HEAD if it really can't work on the generics branch. The two are relatively in sync (just about to do another merge of the two). However, if there is a consensus that we should have such support, may I suggest that you don't write a new class, but instead simply drop the parametric typing from the one on the generics branch and merge this across. This keeps the two fairly in sync, and means that we can just merge the two files when the time comes. As a binary, the compiled version works fine with a VM that only supports 1.4 (I've used an older version of JamVM with enums simply by adding the class onto the classpath with a HEAD build). > I'm looking into making a patch for Classpath that merges Jessie. It is > not ready yet (IMO) to go in now, because it has direct dependencies on > GNU Crypto, which should be changed to only depend on the standard API. > Of course, if people are amenable to this, we could merge Jessie as-is > right now, and then do this work in Classpath CVS. > > Lastly, I'd like to propose a standard mechanism for debug messages in > Classpath, using java.util.logging. The idea is to have > *component-level* logging, where log messages can be emitted not only by > the integer level (INFO, WARNING) but also on whether or not that exact > log level is enabled or not. > > - A global logger for Classpath, which all code should use for > debug messages. > - A subclass of Level that has integer level 'FINE', with > specific component instances for components of Classpath, > such as 'AWT', 'SECURITY', etc. > - An implementation of Filter, with a static singleton, that > maintains a Set of Classpath log levels -- which can be > changed at run-time -- and only allows logging if a > particular log level is in that set. > > The idea here being that you can tune the filter to log a subset of > Classpath functionality (say, something like SECURITY|CRYPTO|JESSIE, if > I was debugging Jessie). This is, again, something I'm going to do > anyway in the context of Jessie, but wanted to know if there was general > interest in this. > These both sound good, particularly the logging idea. FWIW, I've found the logging framework very useful in my own code. > Cheers, > > > _______________________________________________ > Classpath mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/classpath > Cheers, -- Andrew :-) Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments. See http://www.fsf.org/philosophy/no-word-attachments.html No software patents in Europe -- http://nosoftwarepatents.com "Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn." -- Richard Stallman Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html public class gcj extends Freedom implements Java { ... }
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
