River and Java 8

[Dennis Reedy <de...@gmail.com>]

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

RE: River and Java 8

[Bishnu Gautam <bi...@hotmail.com>]

We have used Java 8  with River 2.2.2 in our lab, and don’t see any issues yet. RegardsBishnu

Bishnu Prasad Gautam


> Date: Thu, 30 Apr 2015 18:01:06 +0200
> From: dawid@travellinck.com
> To: dev@river.apache.org
> Subject: Re: River and Java 8
> 
> That's great to know. Have not run into any issues yet, I was just under
> the impression that there were issues.
> I'm going to give it a go next week, and see if our environment is happy
> on 8.
> 
> One possible issue - I wonder what existing data stored in a persistent
> JavaSpace (with collections, etc - complex objects) would do during the
> 7 -> 8 migration.
> The serialized form of many basic Java objects would surely have changed?
> 
> I'll report back to the list if I find anything interesting :-)
> 
> kind regards,
> Dawid
> 
> 
> On 30/04/2015 17:42, Dennis Reedy wrote:
> > 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
> 
> 
 		 	   		  

Re: River and Java 8

[Dawid Loubser <da...@travellinck.com>]

That's great to know. Have not run into any issues yet, I was just under
the impression that there were issues.
I'm going to give it a go next week, and see if our environment is happy
on 8.

One possible issue - I wonder what existing data stored in a persistent
JavaSpace (with collections, etc - complex objects) would do during the
7 -> 8 migration.
The serialized form of many basic Java objects would surely have changed?

I'll report back to the list if I find anything interesting :-)

kind regards,
Dawid


On 30/04/2015 17:42, Dennis Reedy wrote:
> 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

Re: River and Java 8

[Greg Trasuk <tr...@stratuscom.com>]

On Apr 30, 2015, at 12:28 PM, Peter <ji...@zeus.net.au> wrote:

> 
> 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.

Somebody familiar with the code (I’m guessing Peter) needs to do the merge back to trunk.  Or somebody needs to get familiar with the qa_refactor code.

Cheers,

Greg Trasuk.

Re: River and Java 8

[Peter <ji...@zeus.net.au>]

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