Mark Wielaard wrote: > On Sat, 2005-11-19 at 23:40 +0100, Meskauskas Audrius wrote: > > The idea probably is that if we cannot get access to the system > > clipboard, we may still want to cut/copy/paste inside the same > > application (for instance, to move the text fragment in the text > > area being currently edited). With the local clipboard, the > > application can only read the clipboard data that it have placed > > there itself. With the system clipboard, the application may have > > access on some data that are just accidently remaining there; it > > is probably possible to steal a valuable information this way. > > Yes. But the problem was that 1) whenever there was any insecure > access to the clipboard all successive calls would use this local > clipboard and 2) I am not sure it is really valuable to have > (mutually?) insecure code (ex)change the information in a local > clipboard.
It does seem odd, I agree. I guess the burning question is "what does Sun's JRE do?", since we probably ought to be doing the same. As an aside, caching the result of a SecurityManager check is probably something to avoid, and I'm glad to see it was removed in a later commit. (And as another aside, the best way to draw my attention to a thread is a direct mail with an exciting subject ;)) Cheers, Gary _______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches