river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: [Discuss - Remove JRMP and IIOP support]
Date Fri, 13 Nov 2015 19:09:44 GMT

Apologies for being silent.  Very busy over here.

I am fine with this.



Bryan Thompson
Chief Scientist & Founder
4501 Tower Road
Greensboro, NC 27410

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Fri, Nov 13, 2015 at 2:02 PM, Greg Trasuk <trasukg@stratuscom.com> wrote:

> Hello all:
> I’d like to suggest removing JRMP support (i.e. pre-compiled proxy
> classes), and IIOP support (i.e. CORBA).  JRMP is nicely replaced by JERI,
> which offers security and doesn’t require you to create compiled proxy
> classes by running rmic.  JRMP support was originally included in the Jini
> 2.0 release waaay back in 2001 or so, in order to allow backwards
> compatibility with Jini 1.2 installations.  The IIOP support could in
> theory provide compatibility with native CORBA services (does anyone still
> do that?) or EJBs, but to my knowledge, it wasn’t widely used.
> The main reason for pruning theses capabilities is that unused code still
> requires maintenance and increases the chance of bugs.  Also I think that
> as we go forward with refactoring, renaming, restructuring the build and so
> on, it seems wasteful to do that work on code that isn’t actually in use.
> Obviously, the code remains in Subversion and in the 2.2.2 release, so if
> someone wants to get it back, we (or they) could package it into a
> different deliverable.  But I wouldn’t plan on doing that unless there’s
> actual demand for it.
> My thought is to put this out there for discussion - If there is consensus
> after a few days I’ll call a lazy-consensus vote.   I’ll be happy to do the
> work in the 2.2 branch.
> So, I propose to drop support for the following:
> net.jini.jrmp.**
> net.jini.iiop.**
> QA Harness classes that test any of the above.
> Cheers,
> Greg Trasuk

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message