Do you mean unstable api? If so then yes, that might help encourage some more external participation. Developing api in isolation is very difficult, I've tried to keep public visibility minimal, most of my new code is package private, with some publicly exposed api so I can bridge the divide between net.jini and org.apache.
On that note, Dennis Reedy recently raised some fundamental goals we need to work on if we wan't River to continue to grow and become relevant. The new concurrent security manager and policy are used by the qa suite, they've assisted in fixing many minor concurrency bugs, findbugs has also, however findbugs doesn't understand Remote, so reports Remote implementations as bugs. I didn't worry about fixing existing concurrency bugs in our JavaSpaces implementation, mostly due to time constraints, people are probably better off using Rio or Blitz. More recent code replaces URL with URI, this fixed a number of issues and even cleared the way for native windows platform support, without the need for cigwin. However this code is still quite fresh, so I've stalled releasing, hoping people will eyeball the code first. Api for DelegatePermission and DelegateSecurityManager is extremely minimalistic, although I can't see a reason why these couldn't be moved out of trunk and into the permission delegates library. Originally these were included because DelegateSecurityManager needed it's cache flushed by the policy implementation, when policy refresh is called, but now the cache implementation is separate this is no longer necessary. I'd probably mark the RemotePolicy interface as beta. If you add the annotation, I'll make these changes on the weekend. I'm snowed under with work a present, hope to join in the fun again soon. Cheers, Peter. ----- Original message ----- > Shall we include a @Beta annotation for classes, methods etc that are > not considered stable? > > Gr. Simon
