You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by jg...@simulexinc.com on 2010/12/29 07:37:32 UTC
light refactoring
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: 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