You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2010/12/26 13:52:20 UTC
Suggestion for future
Gang,
There is a strong distributed tradition in the group of people here,
yet unable to communicate the 'purpose' of River. Large companies look
at Gigaspaces, pays good money for it and asked if liking Jini, most
will go "Huh? Why would we use that?", mostly ignorant to the fact
that Jini specs drove Gigaspaces into where it is.
At my company, we are doing evaluations of distributed technologies at
the moment. Jini/River is not even on the map, because it "misses the
points" that are our starting point. But an open source contender like
Hazelcast is, because it delivers an 'starting point' which is easy to
understand, i.e. a list of features as Distributed
Map/Queue/Events/Executor/... expressed in terminology that we (the
users) already know.
So here is my modest suggestion for the Jini community; If you are as
hot on distributed technology as you think you are, then start
thinking in terms (and deliver a clear message) that matters to the
users;
* Full Resilience to failure possible, preferably expressed in SLA.
* APIs expressed in well-known interfaces.
* Avoid confusing the users with underlying tech
* Packaged with reasonable defaults and ease of use.
/me ducking for the flames.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
Re: light refactoring
Posted by Patricia Shanahan <pa...@acm.org>.
How about using an IDE to find all references to the Method-getting
methods? There should not be a whole lot of places that use reflection,
and therefore need a Method object.
Which is better, and how much work is involved, depends on how directly
the method names get to the getMethod calls.
Patricia
Tom Hobbs wrote:
> Besides searching the entire code base for the string names of every
> method, is there anyway to easily get a list of reflectively used
> methods? Or does anyone have a list of the (hopefully few) such
> methods?
>
> On Thu, Dec 30, 2010 at 1:56 PM, Brian Murphy <bt...@gmail.com> wrote:
>> On Wed, Dec 29, 2010 at 1:37 AM, <jg...@simulexinc.com> wrote:
>>
>> 3) Several of the "Constrainable" classes have the private method
>>> "getProxyTrustIterator" which is never used. Is this safe to remove?
>>
>> No, this will break outrigger with respect to remote security.
>>
>> The getProxyTrustIterator method is called reflectively by the
>> infrastructure, and is necessary for verifying trust in the proxies
>> (both dynamic and non-dynamic) that a client might receive.
>> Therefore, that method is somewhat fundamental to the
>> extensions that were made to the Java security model to
>> support network security in the face of remote method
>> invocations and downloaded code. From the specification of
>> the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
>> method:
>>
>> [snip]
>> * A verifier is obtained from a candidate object as follows.
>> * <ul>
>> * <li>
>> * If either the candidate object's class has a non-<code>static</code>
>> * member method with signature:
>> * <pre>ProxyTrustIterator getProxyTrustIterator();</pre>
>> * or the candidate object is an instance of a dynamically generated
>> * {@link Proxy} class and the contained invocation handler's class has
>> * such a member method, then the <code>getProxyTrustIterator</code>
>> * method is called (on the candidate object or its invocation handler).
>> * For each object produced by the {@link ProxyTrustIterator#next next}
>> * method of the returned iterator, the following substeps are used,
>> until
>> * either a verifier is obtained or the iteration terminates. If no
>> * verifier can be obtained from any object produced by the iterator,
>> * then there is no verifier for the candidate object. For any given
>> * object produced by the iterator, if a verifier cannot be obtained
>> from
>> * the object but an intermediate operation involved in attempting to
>> * obtain a verifier throws a <code>RemoteException</code>, that
>> * exception is passed to the {@link ProxyTrustIterator#setException
>> * setException} method of the iterator, and the iteration continues.
>> * <p>
>> * The <code>getProxyTrustIterator</code> method and the
>> * <code>ProxyTrustIterator</code> methods are all invoked in a
>> * restricted security context. If the specified trust verifier
>> * context contains an {@link UntrustedObjectSecurityContext} instance,
>> * then the security context returned by its
>> * {@link UntrustedObjectSecurityContext#getContext getContext} method
>> * is used. Otherwise, the security context used is equivalent to
>> * the current security context (as returned by
>> * {@link net.jini.security.Security#getContext Security.getContext})
>> with
>> * an additional protection domain combined into the access control
>> * context that contains an empty {@link java.security.CodeSource}
>> * (<code>null</code> location and certificates),
>> * <code>null</code> permissions, <code>null</code> class loader, and
>> * <code>null</code> principals.
>> [snip]
>>
>> I hope this helps,
>> Brian
>>
>
Re: light refactoring
Posted by Tom Hobbs <tv...@googlemail.com>.
Besides searching the entire code base for the string names of every
method, is there anyway to easily get a list of reflectively used
methods? Or does anyone have a list of the (hopefully few) such
methods?
On Thu, Dec 30, 2010 at 1:56 PM, Brian Murphy <bt...@gmail.com> wrote:
> On Wed, Dec 29, 2010 at 1:37 AM, <jg...@simulexinc.com> wrote:
>
> 3) Several of the "Constrainable" classes have the private method
>> "getProxyTrustIterator" which is never used. Is this safe to remove?
>
>
> No, this will break outrigger with respect to remote security.
>
> The getProxyTrustIterator method is called reflectively by the
> infrastructure, and is necessary for verifying trust in the proxies
> (both dynamic and non-dynamic) that a client might receive.
> Therefore, that method is somewhat fundamental to the
> extensions that were made to the Java security model to
> support network security in the face of remote method
> invocations and downloaded code. From the specification of
> the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
> method:
>
> [snip]
> * A verifier is obtained from a candidate object as follows.
> * <ul>
> * <li>
> * If either the candidate object's class has a non-<code>static</code>
> * member method with signature:
> * <pre>ProxyTrustIterator getProxyTrustIterator();</pre>
> * or the candidate object is an instance of a dynamically generated
> * {@link Proxy} class and the contained invocation handler's class has
> * such a member method, then the <code>getProxyTrustIterator</code>
> * method is called (on the candidate object or its invocation handler).
> * For each object produced by the {@link ProxyTrustIterator#next next}
> * method of the returned iterator, the following substeps are used,
> until
> * either a verifier is obtained or the iteration terminates. If no
> * verifier can be obtained from any object produced by the iterator,
> * then there is no verifier for the candidate object. For any given
> * object produced by the iterator, if a verifier cannot be obtained
> from
> * the object but an intermediate operation involved in attempting to
> * obtain a verifier throws a <code>RemoteException</code>, that
> * exception is passed to the {@link ProxyTrustIterator#setException
> * setException} method of the iterator, and the iteration continues.
> * <p>
> * The <code>getProxyTrustIterator</code> method and the
> * <code>ProxyTrustIterator</code> methods are all invoked in a
> * restricted security context. If the specified trust verifier
> * context contains an {@link UntrustedObjectSecurityContext} instance,
> * then the security context returned by its
> * {@link UntrustedObjectSecurityContext#getContext getContext} method
> * is used. Otherwise, the security context used is equivalent to
> * the current security context (as returned by
> * {@link net.jini.security.Security#getContext Security.getContext})
> with
> * an additional protection domain combined into the access control
> * context that contains an empty {@link java.security.CodeSource}
> * (<code>null</code> location and certificates),
> * <code>null</code> permissions, <code>null</code> class loader, and
> * <code>null</code> principals.
> [snip]
>
> I hope this helps,
> Brian
>
Re: light refactoring
Posted by jg...@simulexinc.com.
100% agree; documentation would help, as would warning suppression.
jamesG
-----Original Message-----
From: "Patricia Shanahan" <pa...@acm.org>
Sent: Thursday, December 30, 2010 9:55am
To: river-dev@incubator.apache.org
Subject: Re: light refactoring
If it is not already planned, I suggest adding a comment summarizing
this information. Also, in anything Java 5 or later, the method can be
annotated to suppress any warning about the unused private method, so we
can still aim for warning-free code.
Patricia
On 12/30/2010 5:56 AM, Brian Murphy wrote:
> On Wed, Dec 29, 2010 at 1:37 AM,<jg...@simulexinc.com> wrote:
>
> 3) Several of the "Constrainable" classes have the private method
>> "getProxyTrustIterator" which is never used. Is this safe to remove?
>
>
> No, this will break outrigger with respect to remote security.
>
> The getProxyTrustIterator method is called reflectively by the
> infrastructure, and is necessary for verifying trust in the proxies
> (both dynamic and non-dynamic) that a client might receive.
> Therefore, that method is somewhat fundamental to the
> extensions that were made to the Java security model to
> support network security in the face of remote method
> invocations and downloaded code. From the specification of
> the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
> method:
>
> [snip]
> * A verifier is obtained from a candidate object as follows.
> *<ul>
> *<li>
> * If either the candidate object's class has a non-<code>static</code>
> * member method with signature:
> *<pre>ProxyTrustIterator getProxyTrustIterator();</pre>
> * or the candidate object is an instance of a dynamically generated
> * {@link Proxy} class and the contained invocation handler's class has
> * such a member method, then the<code>getProxyTrustIterator</code>
> * method is called (on the candidate object or its invocation handler).
> * For each object produced by the {@link ProxyTrustIterator#next next}
> * method of the returned iterator, the following substeps are used,
> until
> * either a verifier is obtained or the iteration terminates. If no
> * verifier can be obtained from any object produced by the iterator,
> * then there is no verifier for the candidate object. For any given
> * object produced by the iterator, if a verifier cannot be obtained
> from
> * the object but an intermediate operation involved in attempting to
> * obtain a verifier throws a<code>RemoteException</code>, that
> * exception is passed to the {@link ProxyTrustIterator#setException
> * setException} method of the iterator, and the iteration continues.
> *<p>
> * The<code>getProxyTrustIterator</code> method and the
> *<code>ProxyTrustIterator</code> methods are all invoked in a
> * restricted security context. If the specified trust verifier
> * context contains an {@link UntrustedObjectSecurityContext} instance,
> * then the security context returned by its
> * {@link UntrustedObjectSecurityContext#getContext getContext} method
> * is used. Otherwise, the security context used is equivalent to
> * the current security context (as returned by
> * {@link net.jini.security.Security#getContext Security.getContext})
> with
> * an additional protection domain combined into the access control
> * context that contains an empty {@link java.security.CodeSource}
> * (<code>null</code> location and certificates),
> *<code>null</code> permissions,<code>null</code> class loader, and
> *<code>null</code> principals.
> [snip]
>
> I hope this helps,
> Brian
>
Re: light refactoring
Posted by Patricia Shanahan <pa...@acm.org>.
If it is not already planned, I suggest adding a comment summarizing
this information. Also, in anything Java 5 or later, the method can be
annotated to suppress any warning about the unused private method, so we
can still aim for warning-free code.
Patricia
On 12/30/2010 5:56 AM, Brian Murphy wrote:
> On Wed, Dec 29, 2010 at 1:37 AM,<jg...@simulexinc.com> wrote:
>
> 3) Several of the "Constrainable" classes have the private method
>> "getProxyTrustIterator" which is never used. Is this safe to remove?
>
>
> No, this will break outrigger with respect to remote security.
>
> The getProxyTrustIterator method is called reflectively by the
> infrastructure, and is necessary for verifying trust in the proxies
> (both dynamic and non-dynamic) that a client might receive.
> Therefore, that method is somewhat fundamental to the
> extensions that were made to the Java security model to
> support network security in the face of remote method
> invocations and downloaded code. From the specification of
> the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
> method:
>
> [snip]
> * A verifier is obtained from a candidate object as follows.
> *<ul>
> *<li>
> * If either the candidate object's class has a non-<code>static</code>
> * member method with signature:
> *<pre>ProxyTrustIterator getProxyTrustIterator();</pre>
> * or the candidate object is an instance of a dynamically generated
> * {@link Proxy} class and the contained invocation handler's class has
> * such a member method, then the<code>getProxyTrustIterator</code>
> * method is called (on the candidate object or its invocation handler).
> * For each object produced by the {@link ProxyTrustIterator#next next}
> * method of the returned iterator, the following substeps are used,
> until
> * either a verifier is obtained or the iteration terminates. If no
> * verifier can be obtained from any object produced by the iterator,
> * then there is no verifier for the candidate object. For any given
> * object produced by the iterator, if a verifier cannot be obtained
> from
> * the object but an intermediate operation involved in attempting to
> * obtain a verifier throws a<code>RemoteException</code>, that
> * exception is passed to the {@link ProxyTrustIterator#setException
> * setException} method of the iterator, and the iteration continues.
> *<p>
> * The<code>getProxyTrustIterator</code> method and the
> *<code>ProxyTrustIterator</code> methods are all invoked in a
> * restricted security context. If the specified trust verifier
> * context contains an {@link UntrustedObjectSecurityContext} instance,
> * then the security context returned by its
> * {@link UntrustedObjectSecurityContext#getContext getContext} method
> * is used. Otherwise, the security context used is equivalent to
> * the current security context (as returned by
> * {@link net.jini.security.Security#getContext Security.getContext})
> with
> * an additional protection domain combined into the access control
> * context that contains an empty {@link java.security.CodeSource}
> * (<code>null</code> location and certificates),
> *<code>null</code> permissions,<code>null</code> class loader, and
> *<code>null</code> principals.
> [snip]
>
> I hope this helps,
> Brian
>
Re: light refactoring
Posted by jg...@simulexinc.com.
Thanks for your response; very informative.
I'll have to revise the patch, actually, owing to a similar circumstance with a method I did remove in error.
jamesG
-----Original Message-----
From: "Brian Murphy" <bt...@gmail.com>
Sent: Thursday, December 30, 2010 8:56am
To: river-dev@incubator.apache.org
Subject: Re: light refactoring
On Wed, Dec 29, 2010 at 1:37 AM, <jg...@simulexinc.com> wrote:
3) Several of the "Constrainable" classes have the private method
> "getProxyTrustIterator" which is never used. Is this safe to remove?
No, this will break outrigger with respect to remote security.
The getProxyTrustIterator method is called reflectively by the
infrastructure, and is necessary for verifying trust in the proxies
(both dynamic and non-dynamic) that a client might receive.
Therefore, that method is somewhat fundamental to the
extensions that were made to the Java security model to
support network security in the face of remote method
invocations and downloaded code. From the specification of
the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
method:
[snip]
* A verifier is obtained from a candidate object as follows.
* <ul>
* <li>
* If either the candidate object's class has a non-<code>static</code>
* member method with signature:
* <pre>ProxyTrustIterator getProxyTrustIterator();</pre>
* or the candidate object is an instance of a dynamically generated
* {@link Proxy} class and the contained invocation handler's class has
* such a member method, then the <code>getProxyTrustIterator</code>
* method is called (on the candidate object or its invocation handler).
* For each object produced by the {@link ProxyTrustIterator#next next}
* method of the returned iterator, the following substeps are used,
until
* either a verifier is obtained or the iteration terminates. If no
* verifier can be obtained from any object produced by the iterator,
* then there is no verifier for the candidate object. For any given
* object produced by the iterator, if a verifier cannot be obtained
from
* the object but an intermediate operation involved in attempting to
* obtain a verifier throws a <code>RemoteException</code>, that
* exception is passed to the {@link ProxyTrustIterator#setException
* setException} method of the iterator, and the iteration continues.
* <p>
* The <code>getProxyTrustIterator</code> method and the
* <code>ProxyTrustIterator</code> methods are all invoked in a
* restricted security context. If the specified trust verifier
* context contains an {@link UntrustedObjectSecurityContext} instance,
* then the security context returned by its
* {@link UntrustedObjectSecurityContext#getContext getContext} method
* is used. Otherwise, the security context used is equivalent to
* the current security context (as returned by
* {@link net.jini.security.Security#getContext Security.getContext})
with
* an additional protection domain combined into the access control
* context that contains an empty {@link java.security.CodeSource}
* (<code>null</code> location and certificates),
* <code>null</code> permissions, <code>null</code> class loader, and
* <code>null</code> principals.
[snip]
I hope this helps,
Brian
Re: light refactoring
Posted by Brian Murphy <bt...@gmail.com>.
On Wed, Dec 29, 2010 at 1:37 AM, <jg...@simulexinc.com> wrote:
3) Several of the "Constrainable" classes have the private method
> "getProxyTrustIterator" which is never used. Is this safe to remove?
No, this will break outrigger with respect to remote security.
The getProxyTrustIterator method is called reflectively by the
infrastructure, and is necessary for verifying trust in the proxies
(both dynamic and non-dynamic) that a client might receive.
Therefore, that method is somewhat fundamental to the
extensions that were made to the Java security model to
support network security in the face of remote method
invocations and downloaded code. From the specification of
the net.jini.security.proxytrust.ProxyTrustVerifier.isTrusted
method:
[snip]
* A verifier is obtained from a candidate object as follows.
* <ul>
* <li>
* If either the candidate object's class has a non-<code>static</code>
* member method with signature:
* <pre>ProxyTrustIterator getProxyTrustIterator();</pre>
* or the candidate object is an instance of a dynamically generated
* {@link Proxy} class and the contained invocation handler's class has
* such a member method, then the <code>getProxyTrustIterator</code>
* method is called (on the candidate object or its invocation handler).
* For each object produced by the {@link ProxyTrustIterator#next next}
* method of the returned iterator, the following substeps are used,
until
* either a verifier is obtained or the iteration terminates. If no
* verifier can be obtained from any object produced by the iterator,
* then there is no verifier for the candidate object. For any given
* object produced by the iterator, if a verifier cannot be obtained
from
* the object but an intermediate operation involved in attempting to
* obtain a verifier throws a <code>RemoteException</code>, that
* exception is passed to the {@link ProxyTrustIterator#setException
* setException} method of the iterator, and the iteration continues.
* <p>
* The <code>getProxyTrustIterator</code> method and the
* <code>ProxyTrustIterator</code> methods are all invoked in a
* restricted security context. If the specified trust verifier
* context contains an {@link UntrustedObjectSecurityContext} instance,
* then the security context returned by its
* {@link UntrustedObjectSecurityContext#getContext getContext} method
* is used. Otherwise, the security context used is equivalent to
* the current security context (as returned by
* {@link net.jini.security.Security#getContext Security.getContext})
with
* an additional protection domain combined into the access control
* context that contains an empty {@link java.security.CodeSource}
* (<code>null</code> location and certificates),
* <code>null</code> permissions, <code>null</code> class loader, and
* <code>null</code> principals.
[snip]
I hope this helps,
Brian
Re: Java version for Jini Platform Service Servers
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 30-12-10 13:21, Peter Firmstone wrote:
> Sim IJskes - QCG wrote:
>> Option 2, define modules now:
>>
>> Is a whole lot of work and discussion. In the mean time, valuable
>> patches sit in jira.
> Yes, true, but the patches are being held up by the current release, if
> they contain Java 5 language features, otherwise we should review and
> include them in the release.
>
> Are there any Patches in particular your interested in?
Not specifically, just don't want work go to waste (or stale).
Gr. Sim
Re: Java version for Jini Platform Service Servers
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> Option 2, define modules now:
>
> Is a whole lot of work and discussion. In the mean time, valuable
> patches sit in jira.
Yes, true, but the patches are being held up by the current release, if
they contain Java 5 language features, otherwise we should review and
include them in the release.
Are there any Patches in particular your interested in?
>
> P.S. for those not on river-commits i've started coding some
> modularization from Peter and from the skunk/niclas1 into a
> modules.mdtext page.
>
Cheers,
Peter.
Re: Java version for Jini Platform Service Servers
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 30-12-10 10:14, Peter wrote:
> Option 1, minimum java version for everything:
My favorite. Unless we *all* commit to delivering patches to verify
correctness of more complex constructs.
> Option 2, define modules now:
Is a whole lot of work and discussion. In the mean time, valuable
patches sit in jira.
> Option 3, exemption for a single undisputed subsystem:
My second favorite.
Gr. Sim
P.S. for those not on river-commits i've started coding some
modularization from Peter and from the skunk/niclas1 into a
modules.mdtext page.
Re: Java version for Jini Platform Service Servers
Posted by Peter <ji...@zeus.net.au>.
Feel free to add.
Option 1, minimum java version for everything:
Advantages:
* Don't need a modular build.
* Less work now.
Disadvantages:
* Implementations restricted to minimum platform features.
* Earlier or different platform deployed clients cannot utilise services in a mixed environment.
Option 2, define modules now:
My suggestion:
Two required for each service implementation, server and proxy:
* Reggie
* Mahalo
* Outrigger
* Phoenix
* Mercury
* Fiddler
* Norm
The platform:
* A minimum required Jini platform module.
* Service api module.
* A private implementation library module.
* Policy extensions module.
Then consider each on its individual merits and needs.
Option 3, exemption for a single undisputed subsystem:
If we're experiencing difficulties arriving at a decision, a new outrigger utilising concurrency libraries can be a separate implementation of the existing javaspaces service api and use any java features necessary (just quietly, I think this'll be a huge improvement over the current buggy implementation). The same goes for any other service implementation.
There's also a separate experiment to utilise generics in javaspace.
Modularity appears to satisfy everyones needs, without sacrificing compatibility with earlier or alternate java platforms. (Don't worry Mike, we can have rtsj service implementations if you really need them, these can be based on existing implementations) I experimented recently, it wasn't that hard to break it up into components, I used ant, because I don't have any maven experience, but this should wait until after the river namspace changes, which should happen after the 2.1.3 release.
Cheers,
Peter.
Re: light refactoring
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 29-12-10 20:27, Patricia Shanahan wrote:
> I suggest a formal vote on Java 5 for servers ASAP, so that we know
> where we are.
In principle i'm not against the distinction between servers and
clients, but how are we going to define these profiles?
Can't we declare a minimum requirement of java 5?
Gr. Sim
Re: Java Version for Jini Platform Service Servers
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 29-12-10 23:16, Peter Firmstone wrote:
> Java Minimum Version for Jini Platform Service Server side implementations:
I think there are a few options.
1) go simple and declare a minimum version
2) define modules first and determine versions per subsystem
3) allow an excemption for a single undisputed subsystem
Gr. Sim
Re: api compatibility auditing
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 30-12-10 22:34, Patricia Shanahan wrote:
> Sim IJskes - QCG wrote:
>> On 30-12-10 13:16, Peter Firmstone wrote:
>>> I noticed you were experimenting with source version auditing, how did
>>> that go?
>>
>> I have verification working on class level, against sun jdk 1.5
>> signatures. The only problem i see is that we cannot edit the
>> signatures right now. Craigh suggested a tool based on interface
>> definitions, i should have a look at it as well, but that one requires
>> us to code up all signatures manually so it seems.
>>
>> Did you have a look already at animal-sniffer? A run with CDC
>> signatures could start verification for that platform. The problem is,
>> i cannot find a CDC signatures file.
>
> I don't really understand the purpose of all this. Even if a method
> exists in 1.4, we would still need to test with a 1.4 JVM to be sure the
> code works under 1.4.
It's what i would call a compromise. It is a very extensive process this
QA testing. Animal sniffer does what i says. Verifying what methods with
what signature are called outside of river. It is not perfect. No
testing ever is. I'm happy with it. Until someone comes along and builds
us a super duper N*M platform compatibility testing framework. Until
that moment i see the verification as valuable. Not definitive, but
valuable.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: api compatibility auditing
Posted by Patricia Shanahan <pa...@acm.org>.
Sim IJskes - QCG wrote:
> On 30-12-10 13:16, Peter Firmstone wrote:
>> I noticed you were experimenting with source version auditing, how did
>> that go?
>
> I have verification working on class level, against sun jdk 1.5
> signatures. The only problem i see is that we cannot edit the signatures
> right now. Craigh suggested a tool based on interface definitions, i
> should have a look at it as well, but that one requires us to code up
> all signatures manually so it seems.
>
> Did you have a look already at animal-sniffer? A run with CDC signatures
> could start verification for that platform. The problem is, i cannot
> find a CDC signatures file.
I don't really understand the purpose of all this. Even if a method
exists in 1.4, we would still need to test with a 1.4 JVM to be sure the
code works under 1.4.
I would prefer a QA-based strategy:
1. Make sure the framework allows for configuration of JVM version for
each service.
2. Go over any QA tests that need 1.5, to see if they can reasonably
easily be modified for 1.4, and fix as many as possible.
Given that, do QA tests by default with each component at its minimum
supported Java version, and also do special runs with everything at the
maximum version, currently Java 6.
Does this make any sense?
Or maybe we should just go to Java 5, compile and test with Java 5, and
consider a subset for 1.4-only devices as a special project?
Patricia
Re: api compatibility auditing
Posted by Wade Chandler <hw...@yahoo.com>.
----- Original Message ----
> From: Sim IJskes - QCG <si...@qcg.nl>
> To: river-dev@incubator.apache.org
> Sent: Thu, December 30, 2010 9:10:45 AM
> Subject: api compatibility auditing
>
> On 30-12-10 13:16, Peter Firmstone wrote:
> > I noticed you were experimenting with source version auditing, how did
> > that go?
>
> I have verification working on class level, against sun jdk 1.5 signatures.
>The only problem i see is that we cannot edit the signatures right now. Craigh
>suggested a tool based on interface definitions, i should have a look at it as
>well, but that one requires us to code up all signatures manually so it seems.
>
> Did you have a look already at animal-sniffer? A run with CDC signatures could
>start verification for that platform. The problem is, i cannot find a CDC
>signatures file.
>
Should be able to use the Ant tasks to generate signatures. Just requires
pointing to a classpath from what I understood. Should work for generating a CDC
signature file. If you don't get time soon, I'll see if I can find some to play
with animal-sniffer.
Wade
==================
Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
api compatibility auditing
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 30-12-10 13:16, Peter Firmstone wrote:
> I noticed you were experimenting with source version auditing, how did
> that go?
I have verification working on class level, against sun jdk 1.5
signatures. The only problem i see is that we cannot edit the signatures
right now. Craigh suggested a tool based on interface definitions, i
should have a look at it as well, but that one requires us to code up
all signatures manually so it seems.
Did you have a look already at animal-sniffer? A run with CDC signatures
could start verification for that platform. The problem is, i cannot
find a CDC signatures file.
Gr. Sim
Re: Java Version for Jini Platform Service Servers
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 29-12-10 23:16, Peter Firmstone wrote:
>> Java Minimum Version for Jini Platform Service Server side
>> implementations:
>>
>> Java 6:
>> +1 Peter Firmstone
>
> Peter, do you have a proposal how to verify the compatibility of the
> proxy classes?
>
The most obvious way would be to compile them on the minimum platform
they are required to support. Since some have raised issues with
compiling with a later jdk version for an earlier platform. If any
unsupported methods are introduced they'd be discovered.
The server implementation actually depends on the proxy, so there's
nothing wrong with compiling the proxy using an earlier jdk, then
compiling the server implementation with the latest and requiring the
proxy jar also be loaded on the server as a dependency library.
I noticed you were experimenting with source version auditing, how did
that go?
Cheers,
Peter.
Re: Java Version for Jini Platform Service Servers
Posted by Wade Chandler <hw...@yahoo.com>.
----- Original Message ----
> From: Sim IJskes - QCG <si...@qcg.nl>
> To: river-dev@incubator.apache.org
> Sent: Thu, December 30, 2010 6:10:51 AM
> Subject: Re: Java Version for Jini Platform Service Servers
>
> On 29-12-10 23:16, Peter Firmstone wrote:
> > Java Minimum Version for Jini Platform Service Server side implementations:
> >
> > Java 6:
> > +1 Peter Firmstone
>
> Peter, do you have a proposal how to verify the compatibility of the
> proxy classes?
>
These being the ones where they are being loaded dynamically? These are the
types of cases I was thinking animal-sniffer wouldn't be able to help. These are
where I think the rubber hits the road and the only real way is to run them in
their correct deployment version and see if they pass. i.e. unit tests can load
them and run them correctly... I don't really know any other way around that
unless you wrote some kind of a tree visitor for the sources which could
determine that reflection was being used to lookup and load a class, and even
then, you'd have to have that logic be able to find the exact values being
passed in. Leads me to think the only *real* way to do it is unit tests in the
target platforms.
Wade
==================
Wade Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org
Re: Java Version for Jini Platform Service Servers
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 29-12-10 23:16, Peter Firmstone wrote:
> Java Minimum Version for Jini Platform Service Server side implementations:
>
> Java 6:
> +1 Peter Firmstone
Peter, do you have a proposal how to verify the compatibility of the
proxy classes?
Gr. Sim
[VOTE] Java Version for Jini Platform Service Servers
Posted by Peter Firmstone <ji...@zeus.net.au>.
Java Minimum Version for Jini Platform Service Server side implementations:
Java 6:
+1 Peter Firmstone
Java 5:
Java 1.4:
Background:
Servers are the implementation side of Jini platform services, like
Outrigger, Reggie et al, it has been proposed to take advantage of java
concurrency features to fix issues that exist in current implementations.
Using a modular build, planned for River after renaming com.sun.jini.*
to org.apache.river.impl.*, the Service Server implementations can be
built separately from the Jini Platform. The Service API for these
services would remain in the Jini Platform build.
The River Jini platform implementation would be similar to the existing
release, minus the Service Server implementations. This vote doesn't
apply to the Jini Platform, which will still support earlier platforms
for the time being, it only applies to the Service Server side
implementations.
Requiring a later version of Java for Service Server side
implementations won't affect clients on earlier platforms (proxy's will
still be compiled as Java 1.4 compatible for now), this will only affect
deployment of Services, not their clients.
Please add any additional reasons for requiring a particular platform below:
Christopher Dolan wrote:
> I would list bug fixes (specifically "no Thread.interrupt() classloader
> corruption") or maybe performance enhancements as the major reason for
> JDK 6 rather than newer features. Outside of Swing and JAXB, there
> aren't very many compelling new features in JDK 6 that I'm aware of, and
> certainly not many that River would care about.
>
> Chris
Patricia Shanahan wrote:
> I am indeed working on the assumption of Java 5 for FastList. It is
> going to be very difficult to get the combination of speed and solid
> correctness without depending on the Java 5 memory model, specifically
> the volatile guarantees, and on atomics.
>
> The current implementation is subject, under sufficient stress, to
> intermittent dropped entries and NullPointerException failures.
> Although these problems are easiest to reproduce by stress testing
> FastList directly, the investigation was triggered by an isolated
> failure of an Outrigger JavaSpaces QA stress test.
>
> I suggest a formal vote on Java 5 for servers ASAP, so that we know
> where we are.
>
> Patricia
>
>
> jgrahn@simulexinc.com wrote:
>> My understanding was that we had decided to require Java 5 or 6 for
>> servers (owing mostly to the concurrent packages), though the
>> client-side requirements were left unresolved. I thought Java 5+
>> items were being used in the ongoing FastList refactor.
>>
>> If I was mistaken, obviously some of what I did was invalid.
>>
>> jamesG
>>
>> -----Original Message-----
>> From: "Niclas Hedhman" <ni...@hedhman.org>
>> Sent: Wednesday, December 29, 2010 11:49am
>> To: river-dev@incubator.apache.org
>> Subject: Re: light refactoring
>>
>> On Wed, Dec 29, 2010 at 2:37 PM, <jg...@simulexinc.com> wrote:
>>
>>> Replacing iterator usage with the enhanced for loop (for each).
>>> Added generic usage to internal methods/fields. (Internal use
>>> appeared to be non-controversial, and might ease future development.)
>>> Removed unused imports.
>>
>> I am curious; Has there been a "move to Java 5" decision already??
>>
>> Cheers
>
>
Re: light refactoring
Posted by Patricia Shanahan <pa...@acm.org>.
I am indeed working on the assumption of Java 5 for FastList. It is
going to be very difficult to get the combination of speed and solid
correctness without depending on the Java 5 memory model, specifically
the volatile guarantees, and on atomics.
The current implementation is subject, under sufficient stress, to
intermittent dropped entries and NullPointerException failures. Although
these problems are easiest to reproduce by stress testing FastList
directly, the investigation was triggered by an isolated failure of an
Outrigger JavaSpaces QA stress test.
I suggest a formal vote on Java 5 for servers ASAP, so that we know
where we are.
Patricia
jgrahn@simulexinc.com wrote:
> My understanding was that we had decided to require Java 5 or 6 for servers (owing mostly to the concurrent packages), though the client-side requirements were left unresolved. I thought Java 5+ items were being used in the ongoing FastList refactor.
>
> If I was mistaken, obviously some of what I did was invalid.
>
> jamesG
>
> -----Original Message-----
> From: "Niclas Hedhman" <ni...@hedhman.org>
> Sent: Wednesday, December 29, 2010 11:49am
> To: river-dev@incubator.apache.org
> Subject: Re: light refactoring
>
> On Wed, Dec 29, 2010 at 2:37 PM, <jg...@simulexinc.com> wrote:
>
>> Replacing iterator usage with the enhanced for loop (for each).
>> Added generic usage to internal methods/fields. (Internal use appeared to be non-controversial, and might ease future development.)
>> Removed unused imports.
>
> I am curious; Has there been a "move to Java 5" decision already??
>
> Cheers
Re: light refactoring
Posted by jg...@simulexinc.com.
My understanding was that we had decided to require Java 5 or 6 for servers (owing mostly to the concurrent packages), though the client-side requirements were left unresolved. I thought Java 5+ items were being used in the ongoing FastList refactor.
If I was mistaken, obviously some of what I did was invalid.
jamesG
-----Original Message-----
From: "Niclas Hedhman" <ni...@hedhman.org>
Sent: Wednesday, December 29, 2010 11:49am
To: river-dev@incubator.apache.org
Subject: Re: light refactoring
On Wed, Dec 29, 2010 at 2:37 PM, <jg...@simulexinc.com> wrote:
> Replacing iterator usage with the enhanced for loop (for each).
> Added generic usage to internal methods/fields. (Internal use appeared to be non-controversial, and might ease future development.)
> Removed unused imports.
I am curious; Has there been a "move to Java 5" decision already??
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
Re: light refactoring
Posted by Tom Hobbs <tv...@googlemail.com>.
This was my understanding also, although there remained some
discussions that needed having regarding how we can support other
platforms (1.4?, CDC?)
I vaguely recall that we'd make some code changes up to 1.5, but until
the above had been resolved such things were to be kept safely in
branches... But don't quote me, I might just have invented that bit!
On Wed, Dec 29, 2010 at 9:37 PM, MICHAEL MCGRADY
<mm...@topiatechnology.com> wrote:
> I thought that the discussion did not bleed out but that it reached a limited consensus that River would go to Java 5 but not presently to Java 6. There was no formal vote.
>
> MG
>
>
> On Dec 29, 2010, at 10:40 AM, Sim IJskes - QCG wrote:
>
>> On 29-12-10 17:49, Niclas Hedhman wrote:
>>> On Wed, Dec 29, 2010 at 2:37 PM,<jg...@simulexinc.com> wrote:
>>>
>>>> Replacing iterator usage with the enhanced for loop (for each).
>>>> Added generic usage to internal methods/fields. (Internal use appeared to be non-controversial, and might ease future development.)
>>>> Removed unused imports.
>>>
>>> I am curious; Has there been a "move to Java 5" decision already??
>>
>> No formal vote has been cast. The discussion just bled out.
>>
>> Shall we go for a formal vote?
>>
>> Gr. Sim
>>
>
> Michael McGrady
> Chief Architect
> Topia Technology, Inc.
> Cel 1.253.720.3365
> Work 1.253.572.9712 extension 2037
> mmcgrady@topiatechnology.com
>
>
>
>
Re: light refactoring
Posted by MICHAEL MCGRADY <mm...@topiatechnology.com>.
I thought that the discussion did not bleed out but that it reached a limited consensus that River would go to Java 5 but not presently to Java 6. There was no formal vote.
MG
On Dec 29, 2010, at 10:40 AM, Sim IJskes - QCG wrote:
> On 29-12-10 17:49, Niclas Hedhman wrote:
>> On Wed, Dec 29, 2010 at 2:37 PM,<jg...@simulexinc.com> wrote:
>>
>>> Replacing iterator usage with the enhanced for loop (for each).
>>> Added generic usage to internal methods/fields. (Internal use appeared to be non-controversial, and might ease future development.)
>>> Removed unused imports.
>>
>> I am curious; Has there been a "move to Java 5" decision already??
>
> No formal vote has been cast. The discussion just bled out.
>
> Shall we go for a formal vote?
>
> Gr. Sim
>
Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com
Re: light refactoring
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 29-12-10 17:49, Niclas Hedhman wrote:
> On Wed, Dec 29, 2010 at 2:37 PM,<jg...@simulexinc.com> wrote:
>
>> Replacing iterator usage with the enhanced for loop (for each).
>> Added generic usage to internal methods/fields. (Internal use appeared to be non-controversial, and might ease future development.)
>> Removed unused imports.
>
> I am curious; Has there been a "move to Java 5" decision already??
No formal vote has been cast. The discussion just bled out.
Shall we go for a formal vote?
Gr. Sim
Re: light refactoring
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Dec 29, 2010 at 2:37 PM, <jg...@simulexinc.com> wrote:
> Replacing iterator usage with the enhanced for loop (for each).
> Added generic usage to internal methods/fields. (Internal use appeared to be non-controversial, and might ease future development.)
> Removed unused imports.
I am curious; Has there been a "move to Java 5" decision already??
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
light refactoring
Posted by jg...@simulexinc.com.
I have uploaded a couple of patches under JIRA (388) in which I made a handful of refactors. If I did things correctly, they should all be correctness preserving, causing no net change in functionality, fixing compiler warnings, improving clarity and reducing LOC.
Namely, these are the refactors I performed:
(Some) unused methods removed.
(Some) unused variables removed.
Extracting common code into methods.
Replacing iterator usage with the enhanced for loop (for each).
Added generic usage to internal methods/fields. (Internal use appeared to be non-controversial, and might ease future development.)
Removed unused imports.
After these refactors, which mostly address compiler warnings, I ran FindBugs and addressed a handful of its concerns as well.
I confined my changes to outrigger/space packages. If anyone finds the changes of value, I can comb through other packages; if not, it's no big loss.
A few other notes from my passthrough:
1) outrigger.MatchSetProxy has an unsynched critical region that can cause getSnapshot to fail in normal operation.
2) How much performance is gained via the special cases within outrigger.TxnState vs. a vanilla implementation?
3) Several of the "Constrainable" classes have the private method "getProxyTrustIterator" which is never used. Is this safe to remove?
4) Many of the server-side constants (many used in transaction handling) could be replaced with enumerations. Didn't do anything about that, but it's something to consider.
5) FindBugs marked several cases of fields that were only "usually" synchronized, but I didn't address any of these; they'll require some deeper consideration.
Anyway, thought I'd toss this in, since the refactoring process helps with my own familiarization process. All the better if someone else can benefit.
One last thing, I don't yet have the tests running. So a run through the tests before committing would be advisable.
jamesG
Re: Suggestion for future
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tue, Dec 28, 2010 at 2:27 AM, Z Juhasz <z6...@gmail.com> wrote:
> I deliberately want ot avoid any hints of conclusions as I would like to
> community to discuss these things further.
Well, I read between your lines; "Change the message that Jini/River
is based on Java, and position River for any JVM-based language." and
possibly extend that even further to CLR based ones (which should then
cover 90+ of non-mobile platforms).
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
RE: Suggestion for future
Posted by Z Juhasz <z6...@gmail.com>.
Dan,
There's a lot of good things in your comment below. I'd like to add a few
extra bits based on my experience and my interest in Jini (and its future).
- I agree that Jini is unique in the distributed computing arena in its
philosophy. It recognizes that things fail. Full Stop. The largest part of
the software developer community still things we can just extand (stretch)
serial computing paradigms
a bit and all will be good. I liked Jini's philosophy from the first moment.
Until people don't start building complex distributed systems, they will
never recognise the power in Jini. This may never happen and this community
may as well stay as niche (note that the majority of web service technology
based systems are in fact relatively simple client-server environments).
- The second point is that Jini is heavily relied on objects. I wish everone
remembers Jim Waldo's excellent talk entitled "Do you believe in objects?"
(or such). I wish I had the link to the audio... Do people want objects and
(consequenly) object-based APIs? Current trends favour scripting and mesasge
parsing that I personally dont like but one has to live with these.
- Thirdly, on top of object-based semantics, Jini is Java based. I remember
way back at around the year 2002 I talked to several experts in the grid
computing community about Jini and their major problem with it was that 'it
is Java'. By and large industry and large communities are worried about
prescribing one particular language, which is mostly understandable -- even
when the technology offered is clearly superior to those available.
- Finally, Jini is not just Java but is exploiting the ubiquitous Java
platform (the JVM). To me, this is the key point. To have a virtual machine
- and actually it could be any, not just a Java VM - is the most elegant way
to solve the heterogeneity problem in distributed systems. Being able to
develop anything on a laptop and run it virtually anywhere, the result of
this cannot be underestimated. I always thought industry would be buying on
this advantage heavily but I was proved wrong.
I deliberately want ot avoid any hints of conclusions as I would like to
community to discuss these things further.
Cheers,
Zoltan
=================================
Dr Zoltan Juhasz
Dept of Electrical Engineering and Information Systems
University of Pannonia (formerly University of Veszprem)
Veszprem, Hungary
> -----Original Message-----
> From: Dan Creswell [mailto:dan.creswell@gmail.com]
> Sent: 27 December 2010 18:13
> To: river-dev@incubator.apache.org
> Subject: Re: Suggestion for future
>
> I don't think that should put you off, here's why....
>
> We're not talking about distributed computing so much as what
> we want to do with Jini. These are in point of fact two
> different things. First a little bit of dist comp theory,
> this is the last I'll mention, promise:
>
> ConcurrentMap and indeed Map semantics alongside the
> constructs for atomicity (e.g. synchronized) as found in Java
> are not "distributed computing friendly". This is because the
> failure semantics they offer are next to zero (all these
> things provide blocking operations with no timeout that are
> expected to end successfully in very small finite time). The
> only way these work is with a compromise of sufficient
> redundant hardware and reliable networking setups that can
> protect these constructs from failures.
> Similar tradeoffs can be seen with many message queues,
> databases and such.
>
> All this is at odds with the philosophy Jini takes in its
> design which can be summarised as "all dist comp failure
> semantics will be made explicit".
>
> That's all the theory one needs to know for this debate.....
>
> It follows that Jini and many of the so-called distributed
> computing frameworks are fundamentally different beasts. The
> majority want Jini to look like these other beasts as that is
> what they understand, which is fair enough. Alas Jini cannot
> do this without discarding its core philosophy and would
> offer no more value than any other framework were it to do so
> (because that programming philosophy is already well catered for).
>
> Now, the community can choose to support users that want to
> build explicit failure handling into their distributed
> systems or they can choose to eschew that and support users
> that believe in reliable hardware. There is a third way of
> course which is to build something atop Jini that supports
> this opposite philosophy. The trouble with this for me is, as
> I hint above, I personally don't see much in the way of
> benefit over what else is already out there. About the only
> difference would be "powered by Jini" on the box or whatever
> other branding one cares for. Maybe the hardware outlay is
> cheaper as well but for the many small systems built by the
> majority, the difference is negligible.
>
> The "reliable hardware, no failure semantics software" crew
> is the majority of developers so if one wants mass appeal,
> that is where one must go. If one wishes to be niche, that's
> fine too the community just needs to recognise the
> consequences of our choices.
>
> One thing is for sure though, whichever developer group is
> selected as the target audience, a decent starting point will
> still need building. Jini has never had that sorted.
>
> Before anybody flames me, I care not a jot which approach
> people go with, I have my own preference and I believe it
> works better for the kinds of systems I need to build is all.
> These systems are not the norm, they are big, with lots of
> machines, run across a number of datacentres and are heavily
> automated to keep ops costs (including mistakes) down. I use
> a lot of Jini-style constructs and philosophy but tend to end
> up casting my own frameworks to best suit the environment I'm
> working in.
>
>
> On 27 December 2010 16:31, Patricia Shanahan <pa...@acm.org> wrote:
>
> > I think this is a really valuable conversation, and I hope
> it can be
> > brought to a conclusion we can work with. I will not be
> contributing
> > because I don't have sufficient distributed computing background.
> >
> > Patricia
> >
> >
> >
> > Niclas Hedhman wrote:
> >
> >> Gang,
> >>
> >> There is a strong distributed tradition in the group of
> people here,
> >> yet unable to communicate the 'purpose' of River. Large companies
> >> look at Gigaspaces, pays good money for it and asked if
> liking Jini,
> >> most will go "Huh? Why would we use that?", mostly ignorant to the
> >> fact that Jini specs drove Gigaspaces into where it is.
> >>
> >> At my company, we are doing evaluations of distributed
> technologies
> >> at the moment. Jini/River is not even on the map, because
> it "misses
> >> the points" that are our starting point. But an open
> source contender
> >> like Hazelcast is, because it delivers an 'starting point'
> which is
> >> easy to understand, i.e. a list of features as Distributed
> >> Map/Queue/Events/Executor/... expressed in terminology that we (the
> >> users) already know.
> >>
> >> So here is my modest suggestion for the Jini community; If
> you are as
> >> hot on distributed technology as you think you are, then start
> >> thinking in terms (and deliver a clear message) that
> matters to the
> >> users;
> >>
> > ...
> >
>
>
>
> _____________ NOD32 5716 (20101219) Információ _____________
>
> Az üzenetet a NOD32 antivirus system megvizsgálta.
> http://www.nod32.hu
>
Re: Suggestion for future
Posted by Dan Creswell <da...@gmail.com>.
I don't think that should put you off, here's why....
We're not talking about distributed computing so much as what we want to do
with Jini. These are in point of fact two different things. First a little
bit of dist comp theory, this is the last I'll mention, promise:
ConcurrentMap and indeed Map semantics alongside the constructs for
atomicity (e.g. synchronized) as found in Java are not "distributed
computing friendly". This is because the failure semantics they offer are
next to zero (all these things provide blocking operations with no timeout
that are expected to end successfully in very small finite time). The only
way these work is with a compromise of sufficient redundant hardware and
reliable networking setups that can protect these constructs from failures.
Similar tradeoffs can be seen with many message queues, databases and such.
All this is at odds with the philosophy Jini takes in its design which can
be summarised as "all dist comp failure semantics will be made explicit".
That's all the theory one needs to know for this debate.....
It follows that Jini and many of the so-called distributed computing
frameworks are fundamentally different beasts. The majority want Jini to
look like these other beasts as that is what they understand, which is fair
enough. Alas Jini cannot do this without discarding its core philosophy and
would offer no more value than any other framework were it to do so (because
that programming philosophy is already well catered for).
Now, the community can choose to support users that want to build explicit
failure handling into their distributed systems or they can choose to eschew
that and support users that believe in reliable hardware. There is a third
way of course which is to build something atop Jini that supports this
opposite philosophy. The trouble with this for me is, as I hint above, I
personally don't see much in the way of benefit over what else is already
out there. About the only difference would be "powered by Jini" on the box
or whatever other branding one cares for. Maybe the hardware outlay is
cheaper as well but for the many small systems built by the majority, the
difference is negligible.
The "reliable hardware, no failure semantics software" crew is the majority
of developers so if one wants mass appeal, that is where one must go. If one
wishes to be niche, that's fine too the community just needs to recognise
the consequences of our choices.
One thing is for sure though, whichever developer group is selected as the
target audience, a decent starting point will still need building. Jini has
never had that sorted.
Before anybody flames me, I care not a jot which approach people go with, I
have my own preference and I believe it works better for the kinds of
systems I need to build is all. These systems are not the norm, they are
big, with lots of machines, run across a number of datacentres and are
heavily automated to keep ops costs (including mistakes) down. I use a lot
of Jini-style constructs and philosophy but tend to end up casting my own
frameworks to best suit the environment I'm working in.
On 27 December 2010 16:31, Patricia Shanahan <pa...@acm.org> wrote:
> I think this is a really valuable conversation, and I hope it can be
> brought to a conclusion we can work with. I will not be contributing because
> I don't have sufficient distributed computing background.
>
> Patricia
>
>
>
> Niclas Hedhman wrote:
>
>> Gang,
>>
>> There is a strong distributed tradition in the group of people here,
>> yet unable to communicate the 'purpose' of River. Large companies look
>> at Gigaspaces, pays good money for it and asked if liking Jini, most
>> will go "Huh? Why would we use that?", mostly ignorant to the fact
>> that Jini specs drove Gigaspaces into where it is.
>>
>> At my company, we are doing evaluations of distributed technologies at
>> the moment. Jini/River is not even on the map, because it "misses the
>> points" that are our starting point. But an open source contender like
>> Hazelcast is, because it delivers an 'starting point' which is easy to
>> understand, i.e. a list of features as Distributed
>> Map/Queue/Events/Executor/... expressed in terminology that we (the
>> users) already know.
>>
>> So here is my modest suggestion for the Jini community; If you are as
>> hot on distributed technology as you think you are, then start
>> thinking in terms (and deliver a clear message) that matters to the
>> users;
>>
> ...
>
Re: Suggestion for future
Posted by Patricia Shanahan <pa...@acm.org>.
I think this is a really valuable conversation, and I hope it can be
brought to a conclusion we can work with. I will not be contributing
because I don't have sufficient distributed computing background.
Patricia
Niclas Hedhman wrote:
> Gang,
>
> There is a strong distributed tradition in the group of people here,
> yet unable to communicate the 'purpose' of River. Large companies look
> at Gigaspaces, pays good money for it and asked if liking Jini, most
> will go "Huh? Why would we use that?", mostly ignorant to the fact
> that Jini specs drove Gigaspaces into where it is.
>
> At my company, we are doing evaluations of distributed technologies at
> the moment. Jini/River is not even on the map, because it "misses the
> points" that are our starting point. But an open source contender like
> Hazelcast is, because it delivers an 'starting point' which is easy to
> understand, i.e. a list of features as Distributed
> Map/Queue/Events/Executor/... expressed in terminology that we (the
> users) already know.
>
> So here is my modest suggestion for the Jini community; If you are as
> hot on distributed technology as you think you are, then start
> thinking in terms (and deliver a clear message) that matters to the
> users;
...
Re: Suggestion for future
Posted by MICHAEL MCGRADY <mm...@topiatechnology.com>.
I am going to say something that I hope will not start a flame war but fear it might. I just have my opinion here and am not advocating for anything, as a possible quell against sparks.
However, for my part I think of spaces (linda then java) in the original Gellertner and friend architecture as being the reason for JINI (River). JINI is great and so on but JavaSpaces and spaces generally is revolutionary to my mind.
MG
On Dec 26, 2010, at 1:06 PM, Tom Hobbs wrote
> Hi Niclas,
>
> Thanks for the suggestion. I can't seen anything in your message that
> might start a flame war.
>
> You raise some good points. Let me respond to a few of them;
>
>> * Full Resilience to failure possible, preferably expressed in SLA.
>
> Agreed, this is definitely needed as it's something we're missing.
> River is lacking a lot of marketing-style stuff, hopefully recent
> updates to the web site are going to start addressing this. I've
> certainly never seen an SLA style document.
>
>> * APIs expressed in well-known interfaces.
>
> I think we have these, what I think is missing though is that there
> are no clear examples of how you can implement certain distributed
> patterns using River bits. And yes, I agree, River terminology is
> expressly unique to the River domain which makes comparing our
> software with others difficult.
>
>> * Packaged with reasonable defaults [snip]
>
> Reggie, Outrigger, Mahalo are all reasonable defaults aren't they?
>
>> * Avoid confusing the users with underlying tech
>> [snip] and ease of use.
>
> This is something very close to what I've been thinking about for
> quite a while. However, whenever bringing it up on this list the
> general feeling (at least, as I interpret it) has been that we/users
> should be using downstream projects to actually Do Stuff. I get the
> feeling that there is not a clear agreement in the River community
> about what it thinks River *is*.
>
> Is it, a complex tech designed for "downstream projects" to do stuff
> with or is it a complex tech aimed at application developers to do
> stuff with directly?
>
> Personally don't see any reason why River can't be both. I've built
> cool stuff directly with River, I've also gone on to re-invent several
> wheels when I could have gone and grabbed a downstream project
> instead.
>
> I don't want to detract from the original point of your message; that
> River needs to start stating itself better if we want to be strong
> contenders next time companies are looking to adopt a tech; but I do
> think that we need to have some discussion about who River's users are
> because that's going to drive what the above documentation looks like.
>
> Like I've already said, I think River is big enough to cover both
> camps. We absolutely should be working with downstream projects to
> standardise certain bits, add functionality and generally makes things
> better. However, I don't believe that we should ignore the developers
> who might be using River directly - even at the cost of possibly
> duplicating certain features of those downstream projects (but by no
> means *everything*!)
>
> I'm interested to hear other people's opinions, particularly those who
> are using River - in whatever capacity.
>
> I'd now like to join you in your hole ducking the flames...
>
> Cheers,
>
> Tom
>
>
> On Sun, Dec 26, 2010 at 1:56 PM, MICHAEL MCGRADY
> <mm...@topiatechnology.com> wrote:
>> No flames here. I am all for this approach. The non-functional values and services drive my thinking.
>>
>> MG
>>
>>
>> On Dec 26, 2010, at 4:52 AM, Niclas Hedhman wrote:
>>
>>> Gang,
>>>
>>> There is a strong distributed tradition in the group of people here,
>>> yet unable to communicate the 'purpose' of River. Large companies look
>>> at Gigaspaces, pays good money for it and asked if liking Jini, most
>>> will go "Huh? Why would we use that?", mostly ignorant to the fact
>>> that Jini specs drove Gigaspaces into where it is.
>>>
>>> At my company, we are doing evaluations of distributed technologies at
>>> the moment. Jini/River is not even on the map, because it "misses the
>>> points" that are our starting point. But an open source contender like
>>> Hazelcast is, because it delivers an 'starting point' which is easy to
>>> understand, i.e. a list of features as Distributed
>>> Map/Queue/Events/Executor/... expressed in terminology that we (the
>>> users) already know.
>>>
>>> So here is my modest suggestion for the Jini community; If you are as
>>> hot on distributed technology as you think you are, then start
>>> thinking in terms (and deliver a clear message) that matters to the
>>> users;
>>>
>>> * Full Resilience to failure possible, preferably expressed in SLA.
>>>
>>> * APIs expressed in well-known interfaces.
>>>
>>> * Avoid confusing the users with underlying tech
>>>
>>> * Packaged with reasonable defaults and ease of use.
>>>
>>>
>>> /me ducking for the flames.
>>>
>>> Cheers
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://www.qi4j.org - New Energy for Java
>>>
>>> I live here; http://tinyurl.com/3xugrbk
>>> I work here; http://tinyurl.com/24svnvk
>>> I relax here; http://tinyurl.com/2cgsug
>>
>>
Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com
Re: Suggestion for future
Posted by Dan Creswell <da...@gmail.com>.
Good email Tom,
I agree with your sentiments entirely.
I think Niclas' commentary on having a starting point is a good one, though
I wouldn't necessarily agree with the solution outline there-in.
I suspect ultimately, we need to agree which users we're serving and what
problems we want to solve for them, the rest, including packaging, APIs,
SLA's or whatever will follow.
Having been through this whole discussion many times and from many angles,
I'd expect no flames but plenty of conflicting views and no resolution. It
would be a big step forwards for the community as a whole to really engage
with this one, not sure if it's ready yet.
Last thing to say:
"And yes, I agree, River terminology is expressly unique to the River domain
which makes comparing our software with others difficult"
The language used internally needn't be the language used externally in
fact, it probably shouldn't be. Consider the linux kernel hackers have their
own terms and such but the language used by e.g. Ubuntu or Redhat in
packaging that up is completely different. Interesting too I think that the
is a layer of vendors between many Linux end users and the kernel team.
Speaks to how River might/could develop..
Happy Christmas,
Dan.
On 26 December 2010 21:06, Tom Hobbs <tv...@googlemail.com> wrote:
> Hi Niclas,
>
> Thanks for the suggestion. I can't seen anything in your message that
> might start a flame war.
>
> You raise some good points. Let me respond to a few of them;
>
> > * Full Resilience to failure possible, preferably expressed in SLA.
>
> Agreed, this is definitely needed as it's something we're missing.
> River is lacking a lot of marketing-style stuff, hopefully recent
> updates to the web site are going to start addressing this. I've
> certainly never seen an SLA style document.
>
> > * APIs expressed in well-known interfaces.
>
> I think we have these, what I think is missing though is that there
> are no clear examples of how you can implement certain distributed
> patterns using River bits. And yes, I agree, River terminology is
> expressly unique to the River domain which makes comparing our
> software with others difficult.
>
> > * Packaged with reasonable defaults [snip]
>
> Reggie, Outrigger, Mahalo are all reasonable defaults aren't they?
>
> > * Avoid confusing the users with underlying tech
> > [snip] and ease of use.
>
> This is something very close to what I've been thinking about for
> quite a while. However, whenever bringing it up on this list the
> general feeling (at least, as I interpret it) has been that we/users
> should be using downstream projects to actually Do Stuff. I get the
> feeling that there is not a clear agreement in the River community
> about what it thinks River *is*.
>
> Is it, a complex tech designed for "downstream projects" to do stuff
> with or is it a complex tech aimed at application developers to do
> stuff with directly?
>
> Personally don't see any reason why River can't be both. I've built
> cool stuff directly with River, I've also gone on to re-invent several
> wheels when I could have gone and grabbed a downstream project
> instead.
>
> I don't want to detract from the original point of your message; that
> River needs to start stating itself better if we want to be strong
> contenders next time companies are looking to adopt a tech; but I do
> think that we need to have some discussion about who River's users are
> because that's going to drive what the above documentation looks like.
>
> Like I've already said, I think River is big enough to cover both
> camps. We absolutely should be working with downstream projects to
> standardise certain bits, add functionality and generally makes things
> better. However, I don't believe that we should ignore the developers
> who might be using River directly - even at the cost of possibly
> duplicating certain features of those downstream projects (but by no
> means *everything*!)
>
> I'm interested to hear other people's opinions, particularly those who
> are using River - in whatever capacity.
>
> I'd now like to join you in your hole ducking the flames...
>
> Cheers,
>
> Tom
>
>
> On Sun, Dec 26, 2010 at 1:56 PM, MICHAEL MCGRADY
> <mm...@topiatechnology.com> wrote:
> > No flames here. I am all for this approach. The non-functional values
> and services drive my thinking.
> >
> > MG
> >
> >
> > On Dec 26, 2010, at 4:52 AM, Niclas Hedhman wrote:
> >
> >> Gang,
> >>
> >> There is a strong distributed tradition in the group of people here,
> >> yet unable to communicate the 'purpose' of River. Large companies look
> >> at Gigaspaces, pays good money for it and asked if liking Jini, most
> >> will go "Huh? Why would we use that?", mostly ignorant to the fact
> >> that Jini specs drove Gigaspaces into where it is.
> >>
> >> At my company, we are doing evaluations of distributed technologies at
> >> the moment. Jini/River is not even on the map, because it "misses the
> >> points" that are our starting point. But an open source contender like
> >> Hazelcast is, because it delivers an 'starting point' which is easy to
> >> understand, i.e. a list of features as Distributed
> >> Map/Queue/Events/Executor/... expressed in terminology that we (the
> >> users) already know.
> >>
> >> So here is my modest suggestion for the Jini community; If you are as
> >> hot on distributed technology as you think you are, then start
> >> thinking in terms (and deliver a clear message) that matters to the
> >> users;
> >>
> >> * Full Resilience to failure possible, preferably expressed in SLA.
> >>
> >> * APIs expressed in well-known interfaces.
> >>
> >> * Avoid confusing the users with underlying tech
> >>
> >> * Packaged with reasonable defaults and ease of use.
> >>
> >>
> >> /me ducking for the flames.
> >>
> >> Cheers
> >> --
> >> Niclas Hedhman, Software Developer
> >> http://www.qi4j.org - New Energy for Java
> >>
> >> I live here; http://tinyurl.com/3xugrbk
> >> I work here; http://tinyurl.com/24svnvk
> >> I relax here; http://tinyurl.com/2cgsug
> >
> > Michael McGrady
> > Chief Architect
> > Topia Technology, Inc.
> > Cel 1.253.720.3365
> > Work 1.253.572.9712 extension 2037
> > mmcgrady@topiatechnology.com
> >
> >
> >
> >
>
Re: Suggestion for future
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Dec 27, 2010 at 5:06 AM, Tom Hobbs <tv...@googlemail.com> wrote:
>> * APIs expressed in well-known interfaces.
>
> I think we have these, what I think is missing though is that there
> are no clear examples of how you can implement certain distributed
> patterns using River bits. And yes, I agree, River terminology is
> expressly unique to the River domain which makes comparing our
> software with others difficult.
I meant "well-known outside River"-interfaces. Or reasonably close
enough that the selling point is easy.
My point with Hazelcast is that they have done the easy-to-market
approach; java.util.concurrent interfaces in a distributed manner.
Easy to understand.
Others focus on DHT --> Easy to get.
River --> Not so sure, and it takes a lot of reading, and once one is
done; Outrigger is a distributed storage space, but not. Mahalo is a
transaction manager, but not what we are used to. Reggie is a service
registry, but actually much more complicated than that (if you read
docs you easily get scared) yet the most useful and solid bit of work.
>> * Packaged with reasonable defaults [snip]
>
> Reggie, Outrigger, Mahalo are all reasonable defaults aren't they?
Uhhh... Can you provide me with a pointer to the equivalent of;
Map m = Hazelcast.getMap( "niclas" );
This makes "entry" is fun.
GigaSpaces have something similar (can't recall the API call off-my-head).
>I get the
> feeling that there is not a clear agreement in the River community
> about what it thinks River *is*.
Yes, you might hit the nail spot on. So, on one hand, if River is for
"app developers" then it is "too cumbersome" and if it is for someone
in between River and the "app developer", then it doesn't provide
enough value to build on, compared to rolling your own (exception
exist of course).
So, I think Jini as a technology is needed "as-is" for the latter
group, I don't think it is enough for River, and I am probably hinting
that more consumable sub-projects on top are needed.
> I don't want to detract from the original point of your message; that
> River needs to start stating itself better if we want to be strong
> contenders next time companies are looking to adopt a tech; but I do
> think that we need to have some discussion about who River's users are
> because that's going to drive what the above documentation looks like.
Case in point; Myself. Big effort for new middle-ware infrastructure
at work. Jini's value proposal is too small to make it a strategic
underlying choice (even compared to rolling an in-house equivalent),
the compromises one has to make are greater than the value offered in
return. Solutions like Coherence, Hazelcast, Newton, Terracotta,
Gigaspaces and others have enough value-add to be considered.
> I'm interested to hear other people's opinions, particularly those who
> are using River - in whatever capacity.
Me too... I am in no way saying that this is 'must' for the project,
just my highly opinionated view of a project I have followed now for
10 years.
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/24svnvk
I relax here; http://tinyurl.com/2cgsug
Re: Suggestion for future
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi Niclas,
Thanks for the suggestion. I can't seen anything in your message that
might start a flame war.
You raise some good points. Let me respond to a few of them;
> * Full Resilience to failure possible, preferably expressed in SLA.
Agreed, this is definitely needed as it's something we're missing.
River is lacking a lot of marketing-style stuff, hopefully recent
updates to the web site are going to start addressing this. I've
certainly never seen an SLA style document.
> * APIs expressed in well-known interfaces.
I think we have these, what I think is missing though is that there
are no clear examples of how you can implement certain distributed
patterns using River bits. And yes, I agree, River terminology is
expressly unique to the River domain which makes comparing our
software with others difficult.
> * Packaged with reasonable defaults [snip]
Reggie, Outrigger, Mahalo are all reasonable defaults aren't they?
> * Avoid confusing the users with underlying tech
> [snip] and ease of use.
This is something very close to what I've been thinking about for
quite a while. However, whenever bringing it up on this list the
general feeling (at least, as I interpret it) has been that we/users
should be using downstream projects to actually Do Stuff. I get the
feeling that there is not a clear agreement in the River community
about what it thinks River *is*.
Is it, a complex tech designed for "downstream projects" to do stuff
with or is it a complex tech aimed at application developers to do
stuff with directly?
Personally don't see any reason why River can't be both. I've built
cool stuff directly with River, I've also gone on to re-invent several
wheels when I could have gone and grabbed a downstream project
instead.
I don't want to detract from the original point of your message; that
River needs to start stating itself better if we want to be strong
contenders next time companies are looking to adopt a tech; but I do
think that we need to have some discussion about who River's users are
because that's going to drive what the above documentation looks like.
Like I've already said, I think River is big enough to cover both
camps. We absolutely should be working with downstream projects to
standardise certain bits, add functionality and generally makes things
better. However, I don't believe that we should ignore the developers
who might be using River directly - even at the cost of possibly
duplicating certain features of those downstream projects (but by no
means *everything*!)
I'm interested to hear other people's opinions, particularly those who
are using River - in whatever capacity.
I'd now like to join you in your hole ducking the flames...
Cheers,
Tom
On Sun, Dec 26, 2010 at 1:56 PM, MICHAEL MCGRADY
<mm...@topiatechnology.com> wrote:
> No flames here. I am all for this approach. The non-functional values and services drive my thinking.
>
> MG
>
>
> On Dec 26, 2010, at 4:52 AM, Niclas Hedhman wrote:
>
>> Gang,
>>
>> There is a strong distributed tradition in the group of people here,
>> yet unable to communicate the 'purpose' of River. Large companies look
>> at Gigaspaces, pays good money for it and asked if liking Jini, most
>> will go "Huh? Why would we use that?", mostly ignorant to the fact
>> that Jini specs drove Gigaspaces into where it is.
>>
>> At my company, we are doing evaluations of distributed technologies at
>> the moment. Jini/River is not even on the map, because it "misses the
>> points" that are our starting point. But an open source contender like
>> Hazelcast is, because it delivers an 'starting point' which is easy to
>> understand, i.e. a list of features as Distributed
>> Map/Queue/Events/Executor/... expressed in terminology that we (the
>> users) already know.
>>
>> So here is my modest suggestion for the Jini community; If you are as
>> hot on distributed technology as you think you are, then start
>> thinking in terms (and deliver a clear message) that matters to the
>> users;
>>
>> * Full Resilience to failure possible, preferably expressed in SLA.
>>
>> * APIs expressed in well-known interfaces.
>>
>> * Avoid confusing the users with underlying tech
>>
>> * Packaged with reasonable defaults and ease of use.
>>
>>
>> /me ducking for the flames.
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://www.qi4j.org - New Energy for Java
>>
>> I live here; http://tinyurl.com/3xugrbk
>> I work here; http://tinyurl.com/24svnvk
>> I relax here; http://tinyurl.com/2cgsug
>
> Michael McGrady
> Chief Architect
> Topia Technology, Inc.
> Cel 1.253.720.3365
> Work 1.253.572.9712 extension 2037
> mmcgrady@topiatechnology.com
>
>
>
>
Re: Suggestion for future
Posted by MICHAEL MCGRADY <mm...@topiatechnology.com>.
No flames here. I am all for this approach. The non-functional values and services drive my thinking.
MG
On Dec 26, 2010, at 4:52 AM, Niclas Hedhman wrote:
> Gang,
>
> There is a strong distributed tradition in the group of people here,
> yet unable to communicate the 'purpose' of River. Large companies look
> at Gigaspaces, pays good money for it and asked if liking Jini, most
> will go "Huh? Why would we use that?", mostly ignorant to the fact
> that Jini specs drove Gigaspaces into where it is.
>
> At my company, we are doing evaluations of distributed technologies at
> the moment. Jini/River is not even on the map, because it "misses the
> points" that are our starting point. But an open source contender like
> Hazelcast is, because it delivers an 'starting point' which is easy to
> understand, i.e. a list of features as Distributed
> Map/Queue/Events/Executor/... expressed in terminology that we (the
> users) already know.
>
> So here is my modest suggestion for the Jini community; If you are as
> hot on distributed technology as you think you are, then start
> thinking in terms (and deliver a clear message) that matters to the
> users;
>
> * Full Resilience to failure possible, preferably expressed in SLA.
>
> * APIs expressed in well-known interfaces.
>
> * Avoid confusing the users with underlying tech
>
> * Packaged with reasonable defaults and ease of use.
>
>
> /me ducking for the flames.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/3xugrbk
> I work here; http://tinyurl.com/24svnvk
> I relax here; http://tinyurl.com/2cgsug
Michael McGrady
Chief Architect
Topia Technology, Inc.
Cel 1.253.720.3365
Work 1.253.572.9712 extension 2037
mmcgrady@topiatechnology.com