You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@usergrid.apache.org by Dave <sn...@gmail.com> on 2015/02/18 21:15:05 UTC
Proposal: Require Java 8 for Usergrid 2.0
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
Re: Proposal: Require Java 8 for Usergrid 2.0
Posted by Todd Nine <to...@gmail.com>.
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 <sn...@gmail.com> wrote:
> On Sat, Feb 21, 2015 at 12:51 PM, Todd Nine <to...@gmail.com> 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 <na...@thelastpickle.com>
> 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 <ro...@rodsimpson.com>
> > wrote:
> > >
> > > > +1
> > > >
> > > >
> > > >
> > > > --
> > > > Rod Simpson
> > > > T @rockerston
> > > > W rodsimpson.com
> > > >
> > > > On February 18, 2015 at 1:16:19 PM, Dave (snoopdave@gmail.com)
> 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
> > >
> >
>
Re: Proposal: Require Java 8 for Usergrid 2.0
Posted by Dave <sn...@gmail.com>.
On Sat, Feb 21, 2015 at 12:51 PM, Todd Nine <to...@gmail.com> 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 <na...@thelastpickle.com> 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 <ro...@rodsimpson.com>
> wrote:
> >
> > > +1
> > >
> > >
> > >
> > > --
> > > Rod Simpson
> > > T @rockerston
> > > W rodsimpson.com
> > >
> > > On February 18, 2015 at 1:16:19 PM, Dave (snoopdave@gmail.com) 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
> >
>
Re: Proposal: Require Java 8 for Usergrid 2.0
Posted by Todd Nine <to...@gmail.com>.
+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 <na...@thelastpickle.com> 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 <ro...@rodsimpson.com> wrote:
>
> > +1
> >
> >
> >
> > --
> > Rod Simpson
> > T @rockerston
> > W rodsimpson.com
> >
> > On February 18, 2015 at 1:16:19 PM, Dave (snoopdave@gmail.com) 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
>
Re: Proposal: Require Java 8 for Usergrid 2.0
Posted by Todd Nine <to...@gmail.com>.
The Java 8 as well as an Arquillian tomcat first pass are nearly done in
the USERGRID-273 branch. Once that's stable. It'll go back into the 2.0
branch.
On Sat, Feb 21, 2015 at 9:15 PM Ed Anuff <ed...@anuff.com> wrote:
> +1
>
> heck, I'd be happy with UG passing all tests on Java 8
>
> On Fri, Feb 20, 2015 at 6:49 PM, Nate McCall <na...@thelastpickle.com>
> 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 <ro...@rodsimpson.com>
> wrote:
> >
> > > +1
> > >
> > >
> > >
> > > --
> > > Rod Simpson
> > > T @rockerston
> > > W rodsimpson.com
> > >
> > > On February 18, 2015 at 1:16:19 PM, Dave (snoopdave@gmail.com) 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
> >
>
Re: Proposal: Require Java 8 for Usergrid 2.0
Posted by Ed Anuff <ed...@anuff.com>.
+1
heck, I'd be happy with UG passing all tests on Java 8
On Fri, Feb 20, 2015 at 6:49 PM, Nate McCall <na...@thelastpickle.com> 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 <ro...@rodsimpson.com> wrote:
>
> > +1
> >
> >
> >
> > --
> > Rod Simpson
> > T @rockerston
> > W rodsimpson.com
> >
> > On February 18, 2015 at 1:16:19 PM, Dave (snoopdave@gmail.com) 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
>
Re: Proposal: Require Java 8 for Usergrid 2.0
Posted by Nate McCall <na...@thelastpickle.com>.
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 <ro...@rodsimpson.com> wrote:
> +1
>
>
>
> --
> Rod Simpson
> T @rockerston
> W rodsimpson.com
>
> On February 18, 2015 at 1:16:19 PM, Dave (snoopdave@gmail.com) 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
Re: Proposal: Require Java 8 for Usergrid 2.0
Posted by Rod Simpson <ro...@rodsimpson.com>.
+1
--
Rod Simpson
T @rockerston
W rodsimpson.com
On February 18, 2015 at 1:16:19 PM, Dave (snoopdave@gmail.com) 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