+1 for the move to Java 8 as well. I feel this needs done in order to build our new graph traversal patterns cleanly and enable more contribution. Otherwise we're going to have a LOT of ugly code in our code base making be barrier to entry higher.
In regards to removing Rx, initially I thought this would be just a find/replace migration. However, after a bit of review today, I'm not sure we should remove it without more discovery for these reasons. 1) Rx has a much richer set of buffer on count and buffer on time time window functions. We could re-implement these ourselves, probably with our own map functions, or potentially find/create a 3rd party library that does these operations. However, it's time we'll be spending on re-inventing the wheel. We use these extensively in our code, so we'll need an equivalent replacement. 2) Rx has implemented back pressure. This was my biggest concern about their "push" model observable, vs the "pull" iterator based model of Java 8. We could upgrade to the latest 1.x to get this functionality. 3) The push system of Rx has been well documented in remote distributed work systems (such as Akka). We'll want to a ensure this integration will work with Java 8 streams as well. A simple POC with a couple of bare webapps on 2 tomcats would be a good enough POC for me. I think we should definitely look at this, moving off Rx 8 to java would simplify our code base. However, I want to ensure that if we make this move, it won't introduce bugs when we implement replacement functions. Thoughts? On Fri, Feb 20, 2015 at 7:49 PM Nate McCall <[email protected]> wrote: > Cassandra has moved to Java 8 only recently fwiw. I'm fine with that for > UG. > > On Wed, Feb 18, 2015 at 12:26 PM, Rod Simpson <[email protected]> wrote: > > > +1 > > > > > > > > -- > > Rod Simpson > > T @rockerston > > W rodsimpson.com > > > > On February 18, 2015 at 1:16:19 PM, Dave ([email protected]) wrote: > > > > In the two-dot-o branch, the new persistence engine uses lots of > functional > > / reactive programming patterns via RxJava. These patterns are a natural > > fit for Usergrid, but RxJava forces us to use a lot of ugly boiler plate > > code and it forces new developers to have to go through the non-trivial > > RxJava learning curve. > > > > > > Moving forward I propose that we should write code using the same > patterns > > that we use with RxJava, but with Java 8 instead. Java 8 allows us to > most > > of the same things that RxJava does, but with much nicer syntax -- and > it's > > going to be much better supported, documented and well-known than RxJava > > will ever be. > > > > > > What do others thing about requiring Java 8 for Usergrid 2.0? > > > > > > Thanks, > > > > - Dave > > > > > > -- > ----------------- > Nate McCall > Austin, TX > @zznate > > Co-Founder & Sr. Technical Consultant > Apache Cassandra Consulting > http://www.thelastpickle.com >
