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