Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

2015-09-09 Thread sebb 
PING.

If I don't hear any response in the next few days I will revert.

On 3 September 2015 at 14:43, sebb  wrote:
> @dbros...@apache.org
>
> This commit still needs to be reverted please.
>
> Whilst it makes calling clone slightly easier, it breaks binary and
> source compatibility.
> The downsides are not worth the convenience.
>
> On 24 August 2015 at 11:18, sebb  wrote:
>> The clone method and Cloneable interface should be treated with
>> caution [1], so I don't think it makes sense to make it easier to use.
>>
>> I would rather see copy methods allied to a suitable interface.
>>
>> [1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4
>>
>> On 24 August 2015 at 11:07, sebb  wrote:
>>> On 24 August 2015 at 10:57, Jörg Schaible  
>>> wrote:
 Hi Sebb,

 sebb wrote:

> On 24 August 2015 at 08:04, Jörg Schaible 
> wrote:
>> Hi Sebb,
>>
>> sebb wrote:
>>
>>> On 23 August 2015 at 23:19,   wrote:
 Author: dbrosius
 Date: Sun Aug 23 22:19:04 2015
 New Revision: 1697267

 URL: http://svn.apache.org/r1697267
 Log:
 remove the need for casting at the clone() call site
>>>
>>> -1
>>>
>>> I was hoping to reduce the number of API changes to the minimum, so we
>>> can potentially release a
>>> version that is binary compatible with 5.2.
>>
>> Are you sure that this is binary incompatible? IIRC it is safe to adjust
>> the return type of clone here.
>
> It's not binary compatible because the return type is part of the
> method signature.
>
> I think it may well be source compatible.

 No, because the exception is no longer thrown (error depends on the 
 compiler
 settings)
>>>
>>> Huh? The commit did not change the throws clauses (there were none)
>>>
 or if someone has overloaded the method with return type Object.
>>>
>>> Here I agree.
>>>
 Cheers,
 Jörg


 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1695425 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: generic/FieldOrMethod.java verifier/statics/Pass3aVerifier.java verifier/structurals/InstConstraintVisi

2015-09-09 Thread sebb 
PING

I am -1 on the commit as it stands; please revert or fix

On 28 August 2015 at 01:43, sebb  wrote:
> On 12 August 2015 at 07:32,   wrote:
>> Author: chas
>> Date: Wed Aug 12 06:32:41 2015
>> New Revision: 1695425
>>
>> URL: http://svn.apache.org/r1695425
>> Log:
>> BCEL-236: remove deprecated FieldOrMethod.getClassType(ConConstantPoolGen)
>
> I think this needs to be reverted or amended.
>
> The new method FieldOrMethod.getLoadClassType(ConstantPoolGen cpg) can
> throw a ClassCastException.
> See below.
>
>> Modified:
>> 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>> 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>> 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/structurals/InstConstraintVisitor.java
>>
>> Modified: 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java?rev=1695425=1695424=1695425=diff
>> ==
>> --- 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>  (original)
>> +++ 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>  Wed Aug 12 06:32:41 2015
>> @@ -95,17 +95,6 @@ public abstract class FieldOrMethod exte
>>  }
>>
>>
>> -/** @return type of the referenced class/interface
>> - * @deprecated If the instruction references an array class,
>> - *the ObjectType returned will be invalid.  Use
>> - *getReferenceType() instead.
>> - */
>> -@Deprecated
>> -public ObjectType getClassType( ConstantPoolGen cpg ) {
>> -return ObjectType.getInstance(getClassName(cpg));
>> -}
>> -
>> -
>>  /**
>>   * Return the reference type representing the class, interface,
>>   * or array class referenced by the instruction.
>> @@ -131,6 +120,6 @@ public abstract class FieldOrMethod exte
>>  /** @return type of the referenced class/interface
>>   */
>>  public ObjectType getLoadClassType( ConstantPoolGen cpg ) {
>> -return getClassType(cpg);
>> +return (ObjectType)getReferenceType(cpg);
>
> ObjectType is not a subclass of ArrayType
>
> It does not seem right to hide the original reason for the deprecation this 
> way.
>
> The code should at least check the object type and throw a better
> exception than CCE
> And the Javadoc should make the pre-condition clear
>
>>  }
>>  }
>>
>> Modified: 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java?rev=1695425=1695424=1695425=diff
>> ==
>> --- 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>  (original)
>> +++ 
>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>  Wed Aug 12 06:32:41 2015
>> @@ -85,6 +85,7 @@ import org.apache.commons.bcel6.generic.
>>  import org.apache.commons.bcel6.generic.ObjectType;
>>  import org.apache.commons.bcel6.generic.PUTSTATIC;
>>  import org.apache.commons.bcel6.generic.RET;
>> +import org.apache.commons.bcel6.generic.ReferenceType;
>>  import org.apache.commons.bcel6.generic.ReturnInstruction;
>>  import org.apache.commons.bcel6.generic.TABLESWITCH;
>>  import org.apache.commons.bcel6.generic.Type;
>> @@ -543,6 +544,15 @@ public final class Pass3aVerifier extend
>>  }
>>  }
>>
>> +private ObjectType getObjectType(FieldInstruction o) {
>> +ReferenceType rt = o.getReferenceType(cpg);
>> +if(rt instanceof ObjectType) {
>> +return (ObjectType)rt;
>> +}
>> +constraintViolated(o, "expecting ObjectType but got "+rt);
>> +return null;
>> +}
>
> Here we see that the code checks the return class, which is fine.
>
>>  /** Checks if the constraints of operands of the said 
>> instruction(s) are satisfied. */
>>   //getfield, putfield, getstatic, putstatic
>>   @Override
>> @@ -555,8 +565,8 @@ public final class Pass3aVerifier extend
>>  }
>>
>>  String field_name = o.getFieldName(cpg);
>> -
>> -JavaClass jc = 
>> Repository.lookupClass(o.getClassType(cpg).getClassName());
>> +
>> +JavaClass jc = 
>> Repository.lookupClass(getObjectType(o).getClassName());
>>  Field[] fields = jc.getFields();
>>  Field f = null;
>>  for (Field field :

Re: [BCEL] deprecation of getClassName in generic/FieldOrMethod

2015-09-09 Thread sebb 
On 4 September 2015 at 18:46, Mark Roberts  wrote:
> I read and understood the comment as to the reasoning, but the problem is the 
> shared code nature of FieldOrMethod.

What comment was that?

> When dealing with a method you know a priori that the object cannot be an 
> array.  Now to get the ClassName of an InvokeInstruction operand you must say 
> invoke.getReferenceType(cp).getClassName().  This seems pretty awkward.  One 
> solution might be to provide an override version of getClassName in 
> InvokeInstruction.

I think that's what I'm suggesting in BCEL-262. I just want to be sure
I have got it right.

> Thanks,
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [BCEL] deprecation of getClassName in generic/FieldOrMethod

2015-09-09 Thread sebb 
On 9 September 2015 at 11:11, sebb  wrote:
> On 4 September 2015 at 18:46, Mark Roberts  wrote:
>> I read and understood the comment as to the reasoning, but the problem is 
>> the shared code nature of FieldOrMethod.
>
> What comment was that?

I see now, you meant the comment against the method
generic.FieldOrMethod.getClassName(ConstantPoolGen cpg)
I thought you were referring to a proposal to deprecate a method.

I agree that the problem is the shared nature of the code.

Also of course the mutability of the CP index, which means that it can
be accidentally changed to point to the wrong type of entry in the
pool.

>> When dealing with a method you know a priori that the object cannot be an 
>> array.  Now to get the ClassName of an InvokeInstruction operand you must 
>> say invoke.getReferenceType(cp).getClassName().  This seems pretty awkward.  
>> One solution might be to provide an override version of getClassName in 
>> InvokeInstruction.
>
> I think that's what I'm suggesting in BCEL-262. I just want to be sure
> I have got it right.
>
>> Thanks,
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1695425 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: generic/FieldOrMethod.java verifier/statics/Pass3aVerifier.java verifier/structurals/InstConstraintVisi

2015-09-09 Thread Chas Honton 
Will work in this evening. (GMT-8). 

Chas

> On Sep 9, 2015, at 2:07 AM, sebb  wrote:
> 
> PING
> 
> I am -1 on the commit as it stands; please revert or fix
> 
>> On 28 August 2015 at 01:43, sebb  wrote:
>>> On 12 August 2015 at 07:32,   wrote:
>>> Author: chas
>>> Date: Wed Aug 12 06:32:41 2015
>>> New Revision: 1695425
>>> 
>>> URL: http://svn.apache.org/r1695425
>>> Log:
>>> BCEL-236: remove deprecated FieldOrMethod.getClassType(ConConstantPoolGen)
>> 
>> I think this needs to be reverted or amended.
>> 
>> The new method FieldOrMethod.getLoadClassType(ConstantPoolGen cpg) can
>> throw a ClassCastException.
>> See below.
>> 
>>> Modified:
>>>
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>>
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>>
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/structurals/InstConstraintVisitor.java
>>> 
>>> Modified: 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java?rev=1695425=1695424=1695425=diff
>>> ==
>>> --- 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>>  (original)
>>> +++ 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/generic/FieldOrMethod.java
>>>  Wed Aug 12 06:32:41 2015
>>> @@ -95,17 +95,6 @@ public abstract class FieldOrMethod exte
>>> }
>>> 
>>> 
>>> -/** @return type of the referenced class/interface
>>> - * @deprecated If the instruction references an array class,
>>> - *the ObjectType returned will be invalid.  Use
>>> - *getReferenceType() instead.
>>> - */
>>> -@Deprecated
>>> -public ObjectType getClassType( ConstantPoolGen cpg ) {
>>> -return ObjectType.getInstance(getClassName(cpg));
>>> -}
>>> -
>>> -
>>> /**
>>>  * Return the reference type representing the class, interface,
>>>  * or array class referenced by the instruction.
>>> @@ -131,6 +120,6 @@ public abstract class FieldOrMethod exte
>>> /** @return type of the referenced class/interface
>>>  */
>>> public ObjectType getLoadClassType( ConstantPoolGen cpg ) {
>>> -return getClassType(cpg);
>>> +return (ObjectType)getReferenceType(cpg);
>> 
>> ObjectType is not a subclass of ArrayType
>> 
>> It does not seem right to hide the original reason for the deprecation this 
>> way.
>> 
>> The code should at least check the object type and throw a better
>> exception than CCE
>> And the Javadoc should make the pre-condition clear
>> 
>>> }
>>> }
>>> 
>>> Modified: 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java?rev=1695425=1695424=1695425=diff
>>> ==
>>> --- 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>>  (original)
>>> +++ 
>>> commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6/verifier/statics/Pass3aVerifier.java
>>>  Wed Aug 12 06:32:41 2015
>>> @@ -85,6 +85,7 @@ import org.apache.commons.bcel6.generic.
>>> import org.apache.commons.bcel6.generic.ObjectType;
>>> import org.apache.commons.bcel6.generic.PUTSTATIC;
>>> import org.apache.commons.bcel6.generic.RET;
>>> +import org.apache.commons.bcel6.generic.ReferenceType;
>>> import org.apache.commons.bcel6.generic.ReturnInstruction;
>>> import org.apache.commons.bcel6.generic.TABLESWITCH;
>>> import org.apache.commons.bcel6.generic.Type;
>>> @@ -543,6 +544,15 @@ public final class Pass3aVerifier extend
>>> }
>>> }
>>> 
>>> +private ObjectType getObjectType(FieldInstruction o) {
>>> +ReferenceType rt = o.getReferenceType(cpg);
>>> +if(rt instanceof ObjectType) {
>>> +return (ObjectType)rt;
>>> +}
>>> +constraintViolated(o, "expecting ObjectType but got "+rt);
>>> +return null;
>>> +}
>> 
>> Here we see that the code checks the return class, which is fine.
>> 
>>> /** Checks if the constraints of operands of the said 
>>> instruction(s) are satisfied. */
>>>  //getfield, putfield, getstatic, putstatic
>>>  @Override
>>> @@ -555,8 +565,8 @@ public final class Pass3aVerifier extend
>>> }
>>> 
>>> String field_name = o.getFieldName(cpg);
>>> -
>>> -JavaClass jc = 
>>>

[RESULT][VOTE][ALL] (lazy consensus) Commons Parent 39 based on RC1

2015-09-09 Thread Bernd Eckenfels 
Hello,

there have been no objections, so I released commons-parent based on
39-RC1.

The next iteration is also opened on the trunk (and I bumped ASF parent
to version 17 as discussed)

Gruss
Bernd

 Am Thu, 27 Aug 2015 15:34:52 +0200
schrieb Bernd Eckenfels :

> Hello All,
> 
> 
> The Apache Commons Parent POM provides common settings for all Apache
> Commons components.
> 
> 
> This is a VOTE to release Commons Parent 39-RC1.
> 
> 
> This VOTE by LAZY-CONSENSUS is open for at least 72 hours until
> August 31 17:00 UTC.
> 
> 
> Changes in this version include:
> 
> Uses a new location assembly location; updates plugins; allows Java 8
> builds to use animal-sniffer.
> 
> Changes in this version include:
> 
> Changes:
> o Update Compiler Plugin : 3.2 -> 3.3
> o Update Build Helper Plugin : 1.8 -> 1.9.1
> o Update Release Plugin : 2.5.1 -> 2.5.2
> o Update Javadoc Plugin : 2.10.2 -> 2.10.3
> o Update Jar Plugin : 2.5 -> 2.6
> o Drop the "trunks-proper" profile
> o Update animal-sniffer Plugin : 2.13 -> 2.14
>   (for Java7+ build profile)
> o Move assembly to standard location.
>   src/main => src/assembly/src.xml
> o Update Jacoco Plugin : 0.7.4.201502262128 -> 0.7.5.201505241946
> 
> 
> The files (staged and md5sums):
>   https://repository.apache.org/content/repositories/orgapachecommons-1113/
> 
>   6ef191d426cf9e2d123b310a2b707f17 commons-parent-39.pom
>   ae2337027f898270d2d7af376bd76ba2 commons-parent-39-site.xml
> 
> 
> The tag:
>   
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-39-RC1/
>   Revision:  r1698146
> 
> The site: None.
> 
> Signed with e...@apache.org:
> https://pgp.mit.edu/pks/lookup?op=get=0xBFFC9B54721244AD
> 
> Greetings
> Bernd

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

2015-09-09 Thread Dave Brosius 

Revert if you like. I'm not sure how it breaks anything.

On 09/09/2015 01:41 PM, sebb wrote:

On 9 September 2015 at 17:57, Gary Gregory  wrote:

On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:


PING.

If I don't hear any response in the next few days I will revert.


Would it be helpful to post a link to what a -1 on a commit means as a
refresher?

By all means.


Gary



On 3 September 2015 at 14:43, sebb  wrote:

@dbros...@apache.org

This commit still needs to be reverted please.

Whilst it makes calling clone slightly easier, it breaks binary and
source compatibility.
The downsides are not worth the convenience.

On 24 August 2015 at 11:18, sebb  wrote:

The clone method and Cloneable interface should be treated with
caution [1], so I don't think it makes sense to make it easier to use.

I would rather see copy methods allied to a suitable interface.

[1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4

On 24 August 2015 at 11:07, sebb  wrote:

On 24 August 2015 at 10:57, Jörg Schaible <

joerg.schai...@swisspost.com> wrote:

Hi Sebb,

sebb wrote:


On 24 August 2015 at 08:04, Jörg Schaible <

joerg.schai...@swisspost.com>

wrote:

Hi Sebb,

sebb wrote:


On 23 August 2015 at 23:19,   wrote:

Author: dbrosius
Date: Sun Aug 23 22:19:04 2015
New Revision: 1697267

URL: http://svn.apache.org/r1697267
Log:
remove the need for casting at the clone() call site

-1

I was hoping to reduce the number of API changes to the minimum,

so we

can potentially release a
version that is binary compatible with 5.2.

Are you sure that this is binary incompatible? IIRC it is safe to

adjust

the return type of clone here.

It's not binary compatible because the return type is part of the
method signature.

I think it may well be source compatible.

No, because the exception is no longer thrown (error depends on the

compiler

settings)

Huh? The commit did not change the throws clauses (there were none)


or if someone has overloaded the method with return type Object.

Here I agree.


Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

2015-09-09 Thread Dave Brosius 
Revert if you like. I'm not sure how it breaks anything. The return type 
is not part of a method signature, so it doesn't break reflection. You 
can override with a method that returns Object. You can assign to 
object. so not sure the issue. But it's not a big deal so, whatever.


On 09/09/2015 01:41 PM, sebb wrote:

On 9 September 2015 at 17:57, Gary Gregory  wrote:

On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:


PING.

If I don't hear any response in the next few days I will revert.


Would it be helpful to post a link to what a -1 on a commit means as a
refresher?

By all means.


Gary



On 3 September 2015 at 14:43, sebb  wrote:

@dbros...@apache.org

This commit still needs to be reverted please.

Whilst it makes calling clone slightly easier, it breaks binary and
source compatibility.
The downsides are not worth the convenience.

On 24 August 2015 at 11:18, sebb  wrote:

The clone method and Cloneable interface should be treated with
caution [1], so I don't think it makes sense to make it easier to use.

I would rather see copy methods allied to a suitable interface.

[1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4

On 24 August 2015 at 11:07, sebb  wrote:

On 24 August 2015 at 10:57, Jörg Schaible <

joerg.schai...@swisspost.com> wrote:

Hi Sebb,

sebb wrote:


On 24 August 2015 at 08:04, Jörg Schaible <

joerg.schai...@swisspost.com>

wrote:

Hi Sebb,

sebb wrote:


On 23 August 2015 at 23:19,   wrote:

Author: dbrosius
Date: Sun Aug 23 22:19:04 2015
New Revision: 1697267

URL: http://svn.apache.org/r1697267
Log:
remove the need for casting at the clone() call site

-1

I was hoping to reduce the number of API changes to the minimum,

so we

can potentially release a
version that is binary compatible with 5.2.

Are you sure that this is binary incompatible? IIRC it is safe to

adjust

the return type of clone here.

It's not binary compatible because the return type is part of the
method signature.

I think it may well be source compatible.

No, because the exception is no longer thrown (error depends on the

compiler

settings)

Huh? The commit did not change the throws clauses (there were none)


or if someone has overloaded the method with return type Object.

Here I agree.


Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

2015-09-09 Thread sebb 
On 10 September 2015 at 01:07, Dave Brosius  wrote:
> Revert if you like.

Thanks!

> I'm not sure how it breaks anything. The return type is
> not part of a method signature, so it doesn't break reflection.

The return type *is* part of the method signature.
You cannot for example replace "int fileSize() with long fileSize()"
and maintain binary compat.
The loader won't find the method.

You can replace void with something else and retain source compat, but
not binary compat.
Even though the return is not used by the code, the loader won't find
the method.

> You can
> override with a method that returns Object.

I just tried, and the compiler complained "The return type is
incompatible with Attribute.clone()"

> You can assign to object. so not
> sure the issue. But it's not a big deal so, whatever.

I agree that at present the issue is moot as there is no previous
version with which to be compatible.

However *if* we can release an updated version of BCEL which is
compatible, that would be much better for downstream users.

So I am trying to minimise API changes that are not essential to fixing bugs.
As such I have reverted many of the changes I made to tidy up the code
in 6.0. I shall probably have to revert more.

> On 09/09/2015 01:41 PM, sebb wrote:
>>
>> On 9 September 2015 at 17:57, Gary Gregory  wrote:
>>>
>>> On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:
>>>
 PING.

 If I don't hear any response in the next few days I will revert.

>>> Would it be helpful to post a link to what a -1 on a commit means as a
>>> refresher?
>>
>> By all means.
>>
>>> Gary
>>>
>>>
 On 3 September 2015 at 14:43, sebb  wrote:
>
> @dbros...@apache.org
>
> This commit still needs to be reverted please.
>
> Whilst it makes calling clone slightly easier, it breaks binary and
> source compatibility.
> The downsides are not worth the convenience.
>
> On 24 August 2015 at 11:18, sebb  wrote:
>>
>> The clone method and Cloneable interface should be treated with
>> caution [1], so I don't think it makes sense to make it easier to use.
>>
>> I would rather see copy methods allied to a suitable interface.
>>
>> [1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4
>>
>> On 24 August 2015 at 11:07, sebb  wrote:
>>>
>>> On 24 August 2015 at 10:57, Jörg Schaible <

 joerg.schai...@swisspost.com> wrote:

 Hi Sebb,

 sebb wrote:

> On 24 August 2015 at 08:04, Jörg Schaible <

 joerg.schai...@swisspost.com>
>
> wrote:
>>
>> Hi Sebb,
>>
>> sebb wrote:
>>
>>> On 23 August 2015 at 23:19,   wrote:

 Author: dbrosius
 Date: Sun Aug 23 22:19:04 2015
 New Revision: 1697267

 URL: http://svn.apache.org/r1697267
 Log:
 remove the need for casting at the clone() call site
>>>
>>> -1
>>>
>>> I was hoping to reduce the number of API changes to the minimum,

 so we
>>>
>>> can potentially release a
>>> version that is binary compatible with 5.2.
>>
>> Are you sure that this is binary incompatible? IIRC it is safe to

 adjust
>>
>> the return type of clone here.
>
> It's not binary compatible because the return type is part of the
> method signature.
>
> I think it may well be source compatible.

 No, because the exception is no longer thrown (error depends on the

 compiler

 settings)
>>>
>>> Huh? The commit did not change the throws clauses (there were none)
>>>
 or if someone has overloaded the method with return type Object.
>>>
>>> Here I agree.
>>>
 Cheers,
 Jörg



 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>

Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

2015-09-09 Thread Gary Gregory 
As a reminder of what a -1 means on a commit, please see
https://www.apache.org/foundation/voting.html, specifically:

"For code-modification votes, +1 votes are in favour of the proposal, but
-1 votes are vetos and kill the proposal dead until all vetoers withdraw
their -1 votes."

and:

"A code-modification proposal may be stopped dead in its tracks by a -1
vote by a qualified voter. This constitutes a veto, and it cannot be
overruled nor overridden by anyone. Vetos stand until and unless withdrawn
by their casters.

To prevent vetos from being used capriciously, they must be accompanied by
a technical justification showing why the change is bad (opens a security
exposure, negatively affects performance, etc. ). A veto without a
justification is invalid and has no weight."

Gary

On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:

> PING.
>
> If I don't hear any response in the next few days I will revert.
>
> On 3 September 2015 at 14:43, sebb  wrote:
> > @dbros...@apache.org
> >
> > This commit still needs to be reverted please.
> >
> > Whilst it makes calling clone slightly easier, it breaks binary and
> > source compatibility.
> > The downsides are not worth the convenience.
> >
> > On 24 August 2015 at 11:18, sebb  wrote:
> >> The clone method and Cloneable interface should be treated with
> >> caution [1], so I don't think it makes sense to make it easier to use.
> >>
> >> I would rather see copy methods allied to a suitable interface.
> >>
> >> [1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4
> >>
> >> On 24 August 2015 at 11:07, sebb  wrote:
> >>> On 24 August 2015 at 10:57, Jörg Schaible <
> joerg.schai...@swisspost.com> wrote:
>  Hi Sebb,
> 
>  sebb wrote:
> 
> > On 24 August 2015 at 08:04, Jörg Schaible <
> joerg.schai...@swisspost.com>
> > wrote:
> >> Hi Sebb,
> >>
> >> sebb wrote:
> >>
> >>> On 23 August 2015 at 23:19,   wrote:
>  Author: dbrosius
>  Date: Sun Aug 23 22:19:04 2015
>  New Revision: 1697267
> 
>  URL: http://svn.apache.org/r1697267
>  Log:
>  remove the need for casting at the clone() call site
> >>>
> >>> -1
> >>>
> >>> I was hoping to reduce the number of API changes to the minimum,
> so we
> >>> can potentially release a
> >>> version that is binary compatible with 5.2.
> >>
> >> Are you sure that this is binary incompatible? IIRC it is safe to
> adjust
> >> the return type of clone here.
> >
> > It's not binary compatible because the return type is part of the
> > method signature.
> >
> > I think it may well be source compatible.
> 
>  No, because the exception is no longer thrown (error depends on the
> compiler
>  settings)
> >>>
> >>> Huh? The commit did not change the throws clauses (there were none)
> >>>
>  or if someone has overloaded the method with return type Object.
> >>>
> >>> Here I agree.
> >>>
>  Cheers,
>  Jörg
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Refresher on -1 on code mods

2015-09-09 Thread Gary Gregory 
Hi All:

Since we just had a -1 on a code modification recently, I want to post a
reminder of what a -1 means in this case, for new committers please read
https://www.apache.org/foundation/voting.html, specifically:

"For code-modification votes, +1 votes are in favour of the proposal, but
-1 votes are vetos and kill the proposal dead until all vetoers withdraw
their -1 votes."

and:

"A code-modification proposal may be stopped dead in its tracks by a -1
vote by a qualified voter. This constitutes a veto, and it cannot be
overruled nor overridden by anyone. Vetos stand until and unless withdrawn
by their casters.

To prevent vetos from being used capriciously, they must be accompanied by
a technical justification showing why the change is bad (opens a security
exposure, negatively affects performance, etc. ). A veto without a
justification is invalid and has no weight."

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

2015-09-09 Thread sebb 
On 9 September 2015 at 17:57, Gary Gregory  wrote:
> On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:
>
>> PING.
>>
>> If I don't hear any response in the next few days I will revert.
>>
>
> Would it be helpful to post a link to what a -1 on a commit means as a
> refresher?

By all means.

> Gary
>
>
>> On 3 September 2015 at 14:43, sebb  wrote:
>> > @dbros...@apache.org
>> >
>> > This commit still needs to be reverted please.
>> >
>> > Whilst it makes calling clone slightly easier, it breaks binary and
>> > source compatibility.
>> > The downsides are not worth the convenience.
>> >
>> > On 24 August 2015 at 11:18, sebb  wrote:
>> >> The clone method and Cloneable interface should be treated with
>> >> caution [1], so I don't think it makes sense to make it easier to use.
>> >>
>> >> I would rather see copy methods allied to a suitable interface.
>> >>
>> >> [1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4
>> >>
>> >> On 24 August 2015 at 11:07, sebb  wrote:
>> >>> On 24 August 2015 at 10:57, Jörg Schaible <
>> joerg.schai...@swisspost.com> wrote:
>>  Hi Sebb,
>> 
>>  sebb wrote:
>> 
>> > On 24 August 2015 at 08:04, Jörg Schaible <
>> joerg.schai...@swisspost.com>
>> > wrote:
>> >> Hi Sebb,
>> >>
>> >> sebb wrote:
>> >>
>> >>> On 23 August 2015 at 23:19,   wrote:
>>  Author: dbrosius
>>  Date: Sun Aug 23 22:19:04 2015
>>  New Revision: 1697267
>> 
>>  URL: http://svn.apache.org/r1697267
>>  Log:
>>  remove the need for casting at the clone() call site
>> >>>
>> >>> -1
>> >>>
>> >>> I was hoping to reduce the number of API changes to the minimum,
>> so we
>> >>> can potentially release a
>> >>> version that is binary compatible with 5.2.
>> >>
>> >> Are you sure that this is binary incompatible? IIRC it is safe to
>> adjust
>> >> the return type of clone here.
>> >
>> > It's not binary compatible because the return type is part of the
>> > method signature.
>> >
>> > I think it may well be source compatible.
>> 
>>  No, because the exception is no longer thrown (error depends on the
>> compiler
>>  settings)
>> >>>
>> >>> Huh? The commit did not change the throws clauses (there were none)
>> >>>
>>  or if someone has overloaded the method with return type Object.
>> >>>
>> >>> Here I agree.
>> >>>
>>  Cheers,
>>  Jörg
>> 
>> 
>>  -
>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>  For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DRAFT] Report from the Apache Commons committee [Gary Gregory]

2015-09-09 Thread Gary Gregory 
Sorry for the late post. This is what I plan on sending the board, it is
due today.

I can update it if you find any issues or want any changes.

Thank you!

Report from the Apache Commons committee [Gary Gregory]



## Description:


The Apache Commons project focuses on all aspects of reusable Java
components.


The Apache Commons components are widely used in many projects, both within
Apache and without.



## Activity:


The last report was in June 10 2015.



## Health report:

Overall, project health is good with *six* releases this period.



## Issues:


There are no issues requiring board attention at this time.



## LDAP committee group/Committership changes:



 - Currently 122 committers and 36 LDAP committee group members.

 - Kristian Rosenvold was added to the LDAP committee group on Sat Jul
04 2015

 - Otmar Ertl was added as a committer on Tue Jul 14 2015



## Releases:


 - CLI-1.3.1 was released Jun 18 2015

 - CONFIGURATION-2.0-beta1 was released Jun 20 2015

 - COMPRESS-1.10 was released on Mon Aug 17 2015

 - POOL-2.4.2 was released on Sat Aug 01 2015

 - DBCP-2.1.1 was released on Thu Aug 06 2015

 - CSV-1.2 was released on Mon Aug 24 2015



## Mailing list activity:



 - dev@commons.apache.org:

- 663 subscribers (up 10 in the last 3 months):

- 655 emails sent to list (715 in previous quarter)



 - iss...@commons.apache.org:

- 311 subscribers (up 0 in the last 3 months):

- 1580 emails sent to list (1873 in previous quarter)



 - u...@commons.apache.org:

- 1216 subscribers (down -3 in the last 3 months):

- 171 emails sent to list (128 in previous quarter)



 - notificati...@commons.apache.org:

- 9 subscribers (up 2 in the last 3 months):

- 350 emails sent to list (610 in previous quarter)





## JIRA activity:



 - 229 JIRA tickets created in the last 3 months

 - 192 JIRA tickets closed/resolved in the last 3 months

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1697267 - in /commons/proper/bcel/trunk/src/main/java/org/apache/commons/bcel6: classfile/ generic/ verifier/structurals/

2015-09-09 Thread Gary Gregory 
On Wed, Sep 9, 2015 at 1:19 AM, sebb  wrote:

> PING.
>
> If I don't hear any response in the next few days I will revert.
>

Would it be helpful to post a link to what a -1 on a commit means as a
refresher?

Gary


> On 3 September 2015 at 14:43, sebb  wrote:
> > @dbros...@apache.org
> >
> > This commit still needs to be reverted please.
> >
> > Whilst it makes calling clone slightly easier, it breaks binary and
> > source compatibility.
> > The downsides are not worth the convenience.
> >
> > On 24 August 2015 at 11:18, sebb  wrote:
> >> The clone method and Cloneable interface should be treated with
> >> caution [1], so I don't think it makes sense to make it easier to use.
> >>
> >> I would rather see copy methods allied to a suitable interface.
> >>
> >> [1] http://my.safaribooksonline.com/9780137150021/ch03lev1sec4
> >>
> >> On 24 August 2015 at 11:07, sebb  wrote:
> >>> On 24 August 2015 at 10:57, Jörg Schaible <
> joerg.schai...@swisspost.com> wrote:
>  Hi Sebb,
> 
>  sebb wrote:
> 
> > On 24 August 2015 at 08:04, Jörg Schaible <
> joerg.schai...@swisspost.com>
> > wrote:
> >> Hi Sebb,
> >>
> >> sebb wrote:
> >>
> >>> On 23 August 2015 at 23:19,   wrote:
>  Author: dbrosius
>  Date: Sun Aug 23 22:19:04 2015
>  New Revision: 1697267
> 
>  URL: http://svn.apache.org/r1697267
>  Log:
>  remove the need for casting at the clone() call site
> >>>
> >>> -1
> >>>
> >>> I was hoping to reduce the number of API changes to the minimum,
> so we
> >>> can potentially release a
> >>> version that is binary compatible with 5.2.
> >>
> >> Are you sure that this is binary incompatible? IIRC it is safe to
> adjust
> >> the return type of clone here.
> >
> > It's not binary compatible because the return type is part of the
> > method signature.
> >
> > I think it may well be source compatible.
> 
>  No, because the exception is no longer thrown (error depends on the
> compiler
>  settings)
> >>>
> >>> Huh? The commit did not change the throws clauses (there were none)
> >>>
>  or if someone has overloaded the method with return type Object.
> >>>
> >>> Here I agree.
> >>>
>  Cheers,
>  Jörg
> 
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Project Jigsaw: Early-Access Builds available on jdk9.java.net/jigsaw

2015-09-09 Thread Rory O'Donnell 


Hi Benedikt,

Early-access builds of JDK 9 with Project Jigsaw are available for 
download at jdk9.java.net/jigsaw .


The EA builds contain the latest prototype implementation of JSR 376 
, the Java Platform Module 
System,
as well as that of the JDK-specific APIs and tools described in JEP 261 
.


If you'd like to try out the EA builds, by far the most helpful things 
you can do are:


 *

   Try to run existing applications, without change, on these builds to
   see whether the module system, or the modularization of the
   platform, breaks your code or identifies code that depends upon
   JDK-internal APIs or other unspecified aspects of the platform.

 *

   Experiment with the module system itself, perhaps by following the
   quick start guide
   , and start
   thinking about how to migrate existing libraries and application
   components to modules. We hope to publish some specific migration
   tips shortly.

Please send usage questions and experience reports to the jigsaw-dev 
 list. 
Specific suggestions about the design of the module system should be 
sent to the JSR 376 Expert Group's comments list 
.


For more information please seen Mark Reinhold's mail [1]

Rgds,Rory

[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004480.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland