+1 to that! On Sun, 2005-06-05 at 11:53 -0400, Aaron wrote: > From what I understood from this thread (and of course my understanding > could be wrong), there is some contention over where to "hide" this > Classlib-VM interface and implementation so that user code is least able > to use/abuse it. One suggestion was to use existing package visibility > modifiers and stash the classes in java.lang. Another was to take these > classes and put them in a package other than java.lang to keep java.lang > "pure" (at which point they presumably would have to be "public"). > Another was to use classloader or VM "magic" (or perhaps some more > sophisticated module publishing scheme) to hide the existence of these > classes. > > In my humble opinion, I'm not overly concerned about spending a lot of > effort to "hide" this code from application code, because it is already > demonstrably wrong to use them (from user code), and with the proper > measures one can easily circumvent the security manager and access > hidden fields/methods anyway. > > Frankly, > move-forward-with-Classpath-design-and-change-in-the-future-if-we-need-to > sounds fine to me. > > Aaron >