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