date:20130218

Benedikt Ritter created BEANUTILS-423:
-

 Summary: [BeanUtils2] Add test case for BeanAccessor.cast() 
 Key: BEANUTILS-423
 URL: https://issues.apache.org/jira/browse/BEANUTILS-423
 Project: Commons BeanUtils
  Issue Type: Bug
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter


A test for BeanAccessor.cast() should be added

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (BEANUTILS-423) [BeanUtils2] Add test case for BeanAccessor.cast()


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved BEANUTILS-423.
---

Resolution: Invalid

Accidentally created this issue for BeanUtils1 rather than SANDBOX. This issue 
is invalid.

 [BeanUtils2] Add test case for BeanAccessor.cast() 
 ---

 Key: BEANUTILS-423
 URL: https://issues.apache.org/jira/browse/BEANUTILS-423
 Project: Commons BeanUtils
  Issue Type: Bug
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter

 A test for BeanAccessor.cast() should be added

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SANDBOX-443) [BeanUtils2] Add test case for BeanAccessor.cast()

Benedikt Ritter created SANDBOX-443:
---

 Summary: [BeanUtils2] Add test case for BeanAccessor.cast()
 Key: SANDBOX-443
 URL: https://issues.apache.org/jira/browse/SANDBOX-443
 Project: Commons Sandbox
  Issue Type: Improvement
  Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
Priority: Minor
 Fix For: Nightly Builds


A test case for BeanAccessor.cast() should be added.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SANDBOX-443) [BeanUtils2] Add test case for BeanAccessor.cast()


 [ 
https://issues.apache.org/jira/browse/SANDBOX-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved SANDBOX-443.
-

Resolution: Fixed

Added test case in r1446886.

 [BeanUtils2] Add test case for BeanAccessor.cast()
 --

 Key: SANDBOX-443
 URL: https://issues.apache.org/jira/browse/SANDBOX-443
 Project: Commons Sandbox
  Issue Type: Improvement
  Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
Priority: Minor
 Fix For: Nightly Builds


 A test case for BeanAccessor.cast() should be added.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SANDBOX-444) [BeanUtils2] Add test case for BeanProperties.hasProperty()


 [ 
https://issues.apache.org/jira/browse/SANDBOX-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved SANDBOX-444.
-

Resolution: Fixed

Added in r1446874.

 [BeanUtils2] Add test case for BeanProperties.hasProperty()
 ---

 Key: SANDBOX-444
 URL: https://issues.apache.org/jira/browse/SANDBOX-444
 Project: Commons Sandbox
  Issue Type: Improvement
  Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
Priority: Minor
 Fix For: Nightly Builds


 A test case for BeanProperties.hasProperty() should be added.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CODEC-167) Test our decode with pad character in the middle

Julius Davies created CODEC-167:
---

 Summary: Test our decode with pad character in the middle
 Key: CODEC-167
 URL: https://issues.apache.org/jira/browse/CODEC-167
 Project: Commons Codec
  Issue Type: Test
Affects Versions: 1.7
Reporter: Julius Davies
Priority: Trivial


We don't have any tests in place for decoding something like 
SGVsbG8gV29ybGQ=SGVsbG8gV29ybGQ= where there is a pad character in the middle.

I think our behaviour unwittingly changed for this kind of input between 1.3 
and 1.4.

Here's a unit test so we don't make that mistake again!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CODEC-167) Test our decode with pad character in the middle


 [ 
https://issues.apache.org/jira/browse/CODEC-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julius Davies updated CODEC-167:


Attachment: codec-167.patch

Patch that creates unit test attached.

 Test our decode with pad character in the middle
 

 Key: CODEC-167
 URL: https://issues.apache.org/jira/browse/CODEC-167
 Project: Commons Codec
  Issue Type: Test
Affects Versions: 1.7
Reporter: Julius Davies
Priority: Trivial
 Attachments: codec-167.patch


 We don't have any tests in place for decoding something like 
 SGVsbG8gV29ybGQ=SGVsbG8gV29ybGQ= where there is a pad character in the 
 middle.
 I think our behaviour unwittingly changed for this kind of input between 1.3 
 and 1.4.
 Here's a unit test so we don't make that mistake again!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CODEC-167) Test our decode with pad character in the middle


 [ 
https://issues.apache.org/jira/browse/CODEC-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julius Davies resolved CODEC-167.
-

   Resolution: Fixed
Fix Version/s: 1.8

 Test our decode with pad character in the middle
 

 Key: CODEC-167
 URL: https://issues.apache.org/jira/browse/CODEC-167
 Project: Commons Codec
  Issue Type: Test
Affects Versions: 1.7
Reporter: Julius Davies
Priority: Trivial
 Fix For: 1.8

 Attachments: codec-167.patch


 We don't have any tests in place for decoding something like 
 SGVsbG8gV29ybGQ=SGVsbG8gV29ybGQ= where there is a pad character in the 
 middle.
 I think our behaviour unwittingly changed for this kind of input between 1.3 
 and 1.4.
 Here's a unit test so we don't make that mistake again!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CODEC-166) Base64 could be faster


[ 
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13567090#comment-13567090
 ] 

Julius Davies edited comment on CODEC-166 at 2/18/13 7:11 PM:
--

Here's one way of doing it:  retrofit MiGBase64.java so that it becomes our 
back-end on all the byte[] and String based methods.

All the unit tests still pass!  :-)

Of course this patch still needs some work to clean up documentation and code 
style, but I thought I'd put it out there for comment.

Here's the benchmark run now:

{noformat}
  LARGE DATA new byte[12345]

iHarder...
encode 471.0 MB/sdecode 158.0 MB/s
encode 495.0 MB/sdecode 155.0 MB/s

MiGBase64...
encode 497.0 MB/sdecode 215.0 MB/s
encode 510.0 MB/sdecode 211.0 MB/s

Apache Commons Codec...
encode 556.0 MB/sdecode 224.0 MB/s
encode 553.0 MB/sdecode 226.0 MB/s
{noformat}

Encode speed-up about 250% and decode speed-up about 50%.

  was (Author: juliusdavies):
Here's one way of doing it:  retrofit MiGBase64.java so that it becomes our 
back-end on all the byte[] and String based methods.

All the unit tests still pass!  :-)

Of course this patch still needs some work to clean up documentation and code 
style, but I thought I'd put it out there for comment.

Here's the benchmark run now:

{noformat}
  LARGE DATA new byte[12345]

iHarder...
encode 471.0 MB/sdecode 158.0 MB/s
encode 495.0 MB/sdecode 155.0 MB/s

MiGBase64...
encode 497.0 MB/sdecode 215.0 MB/s
encode 510.0 MB/sdecode 211.0 MB/s

Apache Commons Codec...
encode 556.0 MB/sdecode 224.0 MB/s
encode 553.0 MB/sdecode 226.0 MB/s
{noformat}

Encode speed-up about 350% and decode speed-up about 50%.
  
 Base64 could be faster
 --

 Key: CODEC-166
 URL: https://issues.apache.org/jira/browse/CODEC-166
 Project: Commons Codec
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Julius Davies
Assignee: Julius Davies
 Attachments: base64bench.zip, CODEC-166.draft.patch, CODEC-166.patch


 Our Base64 consistently performs 3 times slower compared to MiGBase64 and 
 iHarder in the byte[] and String encode() methods.
 We are pretty good on decode(), though a little slower (approx. 33% slower) 
 than MiGBase64.
 We always win in the Streaming methods (MiGBase64 doesn't do streaming).  
 Yay!  :-) :-) :-)
 I put together a benchmark.  Here's a typical run:
 {noformat}
   LARGE DATA new byte[12345]
 iHarder...
 encode 486.0 MB/sdecode 158.0 MB/s
 encode 491.0 MB/sdecode 148.0 MB/s
 MiGBase64...
 encode 499.0 MB/sdecode 222.0 MB/s
 encode 493.0 MB/sdecode 226.0 MB/s
 Apache Commons Codec...
 encode 142.0 MB/sdecode 146.0 MB/s
 encode 138.0 MB/sdecode 150.0 MB/s
 {noformat}
 I believe the main approach we can consider to improve performance is to 
 avoid array copies at all costs.   MiGBase64 even counts the number of valid 
 Base64 characters ahead of time on decode() to precalculate the result's size 
 and avoid any array copying!
 I suspect this will mean writing out separate execution paths for the String 
 and byte[] methods, and keeping them out of the streaming logic, since the 
 streaming logic is founded on array copy.
 Unfortunately this means we will diminish internal reuse of the streaming 
 implementation, but I think it's the only way to improve performance, if we 
 want to.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CODEC-166) Base64 could be faster

[
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julius Davies updated CODEC-166:

Attachment: CODEC-166.patch

here's the actual patch I plan to commit

Base64 could be faster
--

Key: CODEC-166
URL: https://issues.apache.org/jira/browse/CODEC-166
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.7
Reporter: Julius Davies
Assignee: Julius Davies
Attachments: base64bench.zip, CODEC-166.draft.patch, CODEC-166.patch

Our Base64 consistently performs 3 times slower compared to MiGBase64 and
iHarder in the byte[] and String encode() methods.
We are pretty good on decode(), though a little slower (approx. 33% slower)
than MiGBase64.
We always win in the Streaming methods (MiGBase64 doesn't do streaming).
Yay! :-) :-) :-)
I put together a benchmark. Here's a typical run:
{noformat}
LARGE DATA new byte[12345]
iHarder...
encode 486.0 MB/sdecode 158.0 MB/s
encode 491.0 MB/sdecode 148.0 MB/s
MiGBase64...
encode 499.0 MB/sdecode 222.0 MB/s
encode 493.0 MB/sdecode 226.0 MB/s
Apache Commons Codec...
encode 142.0 MB/sdecode 146.0 MB/s
encode 138.0 MB/sdecode 150.0 MB/s
{noformat}
I believe the main approach we can consider to improve performance is to
avoid array copies at all costs. MiGBase64 even counts the number of valid
Base64 characters ahead of time on decode() to precalculate the result's size
and avoid any array copying!
I suspect this will mean writing out separate execution paths for the String
and byte[] methods, and keeping them out of the streaming logic, since the
streaming logic is founded on array copy.
Unfortunately this means we will diminish internal reuse of the streaming
implementation, but I think it's the only way to improve performance, if we
want to.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CODEC-166) Base64 could be faster

[
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Julius Davies resolved CODEC-166.
-

Resolution: Fixed
Fix Version/s: 1.8

Marking as fixed for now curious what others think.

Base64 could be faster
--

Key: CODEC-166
URL: https://issues.apache.org/jira/browse/CODEC-166
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.7
Reporter: Julius Davies
Assignee: Julius Davies
Fix For: 1.8

Attachments: base64bench.zip, CODEC-166.draft.patch, CODEC-166.patch

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-310:
--

Attachment: SetUniqueListTest.java
SetUniqueList.java
SetUniqueList.patch

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Vahrst updated COLLECTIONS-310:
--

Attachment: (was: SetUniqueListTest.patch)

 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
 ] 

Thomas Vahrst commented on COLLECTIONS-310:
---

SetUniqueList.patch contains JUnit Tests and Variant No. 1 for SetUniqueList. I 
am not sure whether the patch has a correct format (I am not able to re-apply 
the patch in Netbeans...) so I attached the corresponding java files as well.



 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Goodbye);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Goodbye });
   List expectedParentList = Arrays.asList(new Object[] { Hello, 
 World, Goodbye });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList);
   assertTrue(uniqueList.contains(Goodbye)); // fails
   }
   public void testSubListAddDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.add(Hello);
   List expectedSubList = Arrays.asList(new Object[] { World, 
 Hello });
   List expectedParentList = Arrays.asList(new Object[] { World, 
 Hello });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }
   public void testSubListSetDuplicate() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);
   subList.set(0, Hello);
   List expectedSubList = Arrays.asList(new Object[] { Hello });
   List expectedParentList = Arrays.asList(new Object[] { Hello 
 });
   assertEquals(expectedSubList, subList);
   assertEquals(expectedParentList, uniqueList); // fails
   }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-422) getPropertyType return null on second descendant class

2013-02-18 Thread Oliver Heger (JIRA)


[ 
https://issues.apache.org/jira/browse/BEANUTILS-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580823#comment-13580823
 ] 

Oliver Heger commented on BEANUTILS-422:


This is interesting. I also encountered some strange behavior related to 
introspection and BeanUtils on Java 7: The current build of Commons 
Configuration (which uses BeanUtils) fails with an error that no write method 
for a property can be found. I have not had a closer look yet, but I do not 
think that the affected property is an indexed property. In any case, the 
behavior of bean introspection seems to have changed in Java 7.

 getPropertyType return null on second descendant class
 --

 Key: BEANUTILS-422
 URL: https://issues.apache.org/jira/browse/BEANUTILS-422
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.8.3
 Environment: Oracle JDK 1.7.0.10 and later.
Reporter: Alex Crown
Assignee: Oliver Heger
 Attachments: test.zip


 PropertyUtils.getPropertyType() for IndexedProperty works only for first 
 invoked descendant class. 
 Bug reproduced in JDK 1.7.0.10 - 13. In JDK 1.7.0.9 it works fine. As I see, 
 in JDK 1.7.0.10 java.beans.Introspector was changed, but I don't understand 
 how it works.
 *Example*
 *file* is IndexedProperty of the RootBean (attachend to issue) with type 
 ArrayListString.
 RoootBean has two empty descendans: *FirstChildBean* and *SecondChildBean*.
 {code}
 RootBean bean = new FirstChildBean();
 Class propertyType = PropertyUtils.getPropertyType(bean, file[0]);
 System.out.println(propertyType != null ? propertyType.getName() : null);
 -- Expected: java.lang.String, Actual: java.lang.String
 bean = new SecondChildBean();
 propertyType = PropertyUtils.getPropertyType(bean, file[0]);
 System.out.println(propertyType != null ? propertyType.getName() : null);
 -- Expected: java.lang.String, Actual: null
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
 ] 

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 8:54 PM:


SetUniqueList.patch contains JUnit Tests and Variant No. 1 for SetUniqueList. I 
am not sure whether the patch has a correct format (I am not able to re-apply 
the patch in Netbeans...) so I attached the corresponding java files as well.

Some comment to this solution: 
1. During the implementation I recognized, that the existing implementation of 
subList() uses the subList() method on the decorated list and then creates a 
new Set and fills all elements of the sublist into the set. 

Now this issue requires, that a parent list has to be modified on certain 
invocations on a sublist - for example when adding an element to the sublist 
which exists in the parent list somewhere outside the range of the sublist. 
With the current sublist implementation, any attempt to modify a parent list 
fails with a ConcurrentModifiationException. So we have to reimplement the 
sublist functionality inside SetUniqueList and can not reuse the service of 
AbstractListDecorator.

2. When we create a subList on a SetUniqueList, this sublist has to obbey the 
SetUniqueList contracts. The original parent list will have slightly different 
behavior when adding or setting values. When we create a second sublist based 
on the first sublist, this top most list has to provide SetUniqueList semantics.

Example (from JUnit Tests)
{noformat} 
 subList2! e ! f ! g !  offset = 2
 subList1! c ! d ! e ! f ! g ! h !  offset = 2
 list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j !  offset = 0
 -
 Index 0   1   2   3   4   5   6   7   8   9

 Tests adding a 'd' to subList2. This should move the 'd' in subList1 and list 
in the range of subList2
 Expected result:

 subList2! e ! f ! g ! d !  offset = 1
 subList1! c ! e ! f ! g ! d ! h !  offset = 2
 list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j !  offset = 0
 -
 Index 0   1   2   3   4   5   6   7   8   9
{noformat} 












  was (Author: t.vahrst):
SetUniqueList.patch contains JUnit Tests and Variant No. 1 for 
SetUniqueList. I am not sure whether the patch has a correct format (I am not 
able to re-apply the patch in Netbeans...) so I attached the corresponding java 
files as well.


  
 Modifications of a SetUniqueList.subList() invalidate the parent list
 -

 Key: COLLECTIONS-310
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-310
 Project: Commons Collections
  Issue Type: Bug
  Components: List
Affects Versions: 3.2, Nightly Builds
Reporter: Christian Semrau
Priority: Minor
 Fix For: 4.0

 Attachments: SetUniqueList.java, SetUniqueList.patch, 
 SetUniqueListTest.java


 The List returned by SetUniqueList.subList() is again a SetUniqueList. The 
 contract for List.subList() says that the returned list supports all the 
 operations of the parent list, and it is backed by the parent list.
 We have a SetUniqueList uniqueList equal to {Hello, World}. We get a 
 subList containing the last element. Now we add the element Hello, 
 contained in the uniqueList but not in the subList, to the subList.
 What should happen?
 Should the subList behave like a SetUniqueList and add the element - meaning 
 that it changes position in the uniqueList because at the old place it gets 
 removed, so now uniqueList equals {World, Hello} (which fails)?
 Or should the element not be added, because it is already contained in the 
 parent list, thereby violating the SetUniqueList-ness of the subList (which 
 fails)?
 I prefer the former behaviour, because modifications should only be made 
 through the subList and not through the parent list (as explained in 
 List.subList()).
 What should happen if we replace (using set) the subList element World with 
 Hello instead of adding an element?
 The subList should contain only Hello, and for the parent list, the old 
 element 0 (now a duplicate of the just set element 1) should be removed 
 (which fails).
 And of course the parent list should know what happens to it (specifically, 
 its uniqueness Set) (which fails in the current snapshot).
   public void testSubListAddNew() {
   List uniqueList = SetUniqueList.decorate(new ArrayList());
   uniqueList.add(Hello);
   uniqueList.add(World);
   List subList = uniqueList.subList(1, 2);

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:07 PM:

SetUniqueList.patch contains JUnit Tests and Variant No. 1 for SetUniqueList. I
am not sure whether the patch has a correct format (I am not able to re-apply
the patch in Netbeans...) so I attached the corresponding java files as well.

Some comment to this solution:
1. During the implementation I recognized, that the existing implementation of
subList() uses the subList() method on the decorated list and then creates a
new Set and fills all elements of the sublist into the set.

Now this issue requires, that a parent list has to be modified on certain
invocations on a sublist - for example when adding an element to the sublist
which exists in the parent list somewhere outside the range of the sublist.
With the current sublist implementation, any attempt to modify a parent list
fails with a ConcurrentModifiationException. So we have to reimplement the
sublist functionality inside SetUniqueList and can not reuse the service of
AbstractListDecorator.

2. When we create a subList on a SetUniqueList, this sublist has to obbey the
SetUniqueList contracts. The original parent list will have slightly different
behavior when adding or setting values. When we create a second sublist based
on the first sublist, this top most list has to provide SetUniqueList semantics.

Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9

Tests adding a 'd' to subList2. This should move the 'd' in subList1 and list
in the range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

Because of this requirements I decided for Variant No. 1, that every
SetUniqueList holds its own list and set and maintains a reference to it's
parent SetUniqueList and an offset value. The SetUniqueList garantees, that all
parent lists are updated according to the required functionality and that all
offset values are adjusted if necessary. This solution does not use the sublist
functionality of the decorated list but creates allway a new Set *and* List.

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

# a very details javadoc comment for the subList() method, explaining the
behavior.
# the implementation for listIterator(). As already mentioned, a ListIterator
may itself become a sublist (when specifying a start index).

was (Author: t.vahrst):
SetUniqueList.patch contains JUnit Tests and Variant No. 1 for
SetUniqueList. I am not sure whether the patch has a correct format (I am not
able to re-apply the patch in Netbeans...) so I attached the corresponding java
files as well.

Tests adding a 'd' to subList2. This

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:09 PM:

Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

Tests adding a 'd' to subList2. This should

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:10 PM:

Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

(The 'movement' of 'd' causes the ConcurrentModificationException mentioned
above.)

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0
-
Index 0

[jira] [Comment Edited] (COLLECTIONS-310) Modifications of a SetUniqueList.subList() invalidate the parent list

[
https://issues.apache.org/jira/browse/COLLECTIONS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13580821#comment-13580821
]

Thomas Vahrst edited comment on COLLECTIONS-310 at 2/18/13 9:12 PM:

Adds a 'd' to subList2. This should move the 'd' in subList1 and list in the
range of subList2
Expected result:

subList2! e ! f ! g ! d ! offset = 1
subList1! c ! e ! f ! g ! d ! h ! offset = 2
list! a ! b ! c ! e ! f ! g ! d ! h ! i ! j ! offset = 0
-
Index 0 1 2 3 4 5 6 7 8 9
{noformat}

(The 'movement' of 'd' causes the ConcurrentModificationException mentioned
above.)

I copied the existing code for creating a new Set to also create a new List
based on the existing list.

At this time, there are two things missing:

... to be continued with variant no. 2 ...

Example (from JUnit Tests)
{noformat}
subList2! e ! f ! g ! offset = 2
subList1! c ! d ! e ! f ! g ! h ! offset = 2
list! a ! b ! c ! d ! e ! f ! g ! h ! i ! j ! offset = 0

[jira] [Reopened] (CODEC-166) Base64 could be faster