So far in my research, I've found that the 2 components aren't interchangeable due to Java 8 Streams being a pull system, and Rx Java a push. However, the functional concepts are still the same. Most of our operations are map, flatMap, reduce, and collect operations. While the syntax is ugly at the moment due to our java 1.7 runtime, I think when we move to Java8 and start utilizing lambdas, we'll see less of a noticeable difference, and lower the learning curve.
I'm concerned that if we use both Java 8 and Rx Java in our codebase we're not reducing our complexity to the degree I feel we should. I know there's no "one size fits all solution", but I would prefer we pick a handful of common design patterns and move forward with only those. It will make the codebase easier to optimize, easier to grok, and hopefully encourage community contributions. IMHO we should look at the operations in Rx that aren't available and implement them in streams if possible, or we decide to stick with Rx. Either way, I think it will be worth the time to have a singular functional system in the UG codebase. It's already hard enough to grok for new project members, I don't want to make it any more difficult. Shawn is investigating this change in the current sprint. https://issues.apache.org/jira/browse/USERGRID-414 On Sun, 1 Mar 2015 at 09:43 Dave <[email protected]> wrote: > On Sat, Feb 21, 2015 at 12:51 PM, Todd Nine <[email protected]> wrote: > > > +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. > > > > I agree with this. We don't want to rewrite things just for the sake of > it, but I do think that for new code we should prefer Java 8 constructs > over RxJava ones where feasible. > > - Dave > > > > > 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 > > > > > >
