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 <[EMAIL PROTECTED]> wrote:
What is wrong with using the sun class in the interim? On 2/19/07, Jacob Kjome <[EMAIL PROTECTED]> wrote: > > At 04:27 PM 2/19/2007, you wrote: > >On 2/19/07, Jacob Kjome <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> 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 > >[email protected] > > http://www.slf4j.org/mailman/listinfo/dev > > _______________________________________________ > dev mailing list > [email protected] > http://www.slf4j.org/mailman/listinfo/dev > -- - Eric
-- - Eric
_______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
