The issues with Java 8 relate to classdep, you won't be affected if you're using alternative build tools such as Maven.
The qa-refactor branch has updates to make classdep work with java 8, but I make no guarantee that it will find all dependencies of new Java language features, as these haven't been fully tested. My personal preference is for a well defined build structure like Rio uses, as this eliminates a number of potential issues. N.B. I think there are plenty of River users, it's just River hasn't needed to make significant change, 99% of changes are improvements under the hood that improve user experience, they don't impact the public api or backward compatibility. In other words, if you were using Jini 10 years ago, you're good to go today with some minor configuration changes. Also River is more infrastructure these days, with downstream projects value adding. Agree that there needs to be release candidates and a release, I don't have a lot of time at present. If someone want's to create a release candidate, qa-refactor is ready. There were some changes made to trunk after the qa-refactor branch point by Sim that need to be incorporated at some point too. There is a good possibility that JERI in qa-refactor is the worlds fastest RMI implementation, by a good margin. All hotspots are native methods, DNS issues have been fixed, class loading and security are now blisteringly quick. Put it this way, String case conversion during URI normalisation became a hotspot, so it was replaced by bitshift operations. Regards, Peter. ----- Original message ----- > Started a different thread to not conflate the other. > > We are using Java 8 at AFRL, with River 2.2.2, Rio and SORCER > (https://github.com/mwsobol/SORCER) and don’t see any issues. What are > you running into? > > Dennis
