Re: RFC: Jessie, enums, and loggers

[Andrew John Hughes]

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
> address@hidden
> 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