[slf4j-dev] jcl-over-slf4j module not building

[Eric Crahen]

The reason I ask is that I don't have a lot of free time to do throw away
work. I think that the sun.misc class is a reasonable start for an
implementation that everyone can get their hands on and get a better feel
for how it works. If everyone accepts that as a superior solution I'll be
more than happy to provide a drop in replacement.

On 2/19/07, Eric Crahen <eric.crahen.lists at gmail.com> wrote:
>
> What is wrong with using the sun class in the interim?
>
> On 2/19/07, Jacob Kjome <hoju at visi.com> wrote:
> >
> > At 04:27 PM 2/19/2007, you wrote:
> > >On 2/19/07, Jacob Kjome <<mailto:hoju at visi.com>hoju at visi.com> wrote:
> > >
> > >BTW, if SLF4J used the Service API, I think it would have to be a home
> > grown
> > >one.  Clearly SLF4J cannot depend on com.sun.* or JDK1.6.  So, the
> > Service
> > >stuff would have to be written from scratch and shipped with the
> > >API.  I'm not
> > >sure how involved this would be as I'm not sure how much plumbing code
> > would
> > >need to be written.  Eric, can you address this point?
> > >
> > >
> > >The common practice is use to the sun.misc.* version to get going
> > >quickly. Although this is a sun.misc.* class, its actually pretty
> > >stable, and they (Sun) do a decent job of keeping it compatible
> > >since a lot of people use it - like the Base64Encoder class. If you
> > >want to garuntee the solution still works on non-Sun JVMs, or you
> > >are just generally more comfortable not using using the sun.misc.*
> > >classes, it is fairly trivial to start with the sun.misc.* one for
> > >now; and drop in a replacement that we write. Its not too difficult
> > >to make up your own - its really a pretty simple class.
> >
> > I'm quite sure that depending on com.sun.* is not an option for an
> > open source project.  I'd never allow it for Log4j and I can't
> > imagine the SLF4J developers would allow it.  I suggest that you come
> > up with an implementation of the service API for proposed inclusion
> > in SLF4J.  There's no guarantee it would be accepted.  In fact, the
> > odds seem against it.  However, I highly doubt the SLF4J developers
> > are going to take the time to write it.  So, the only way this has a
> > chance of moving forward is for someone to write it and propose it as
> > SLF4J's non-JDK-specific Services implementation.  Not just
> > pseudo-code, but actual fully implemented working code.
> >
> > Jake
> >
> >
> >
> > >--
> > >
> > >- Eric
> > >_______________________________________________
> > >dev mailing list
> > >dev at slf4j.org
> > > http://www.slf4j.org/mailman/listinfo/dev
> >
> > _______________________________________________
> > dev mailing list
> > dev at slf4j.org
> > http://www.slf4j.org/mailman/listinfo/dev
> >
>
>
>
> --
>
> - Eric




-- 

- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070219/268a98e5/attachment.htm>