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
_______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
