from:"Mark Roberts"

RE: [VOTE] Release Apache Commons BCEL 6.8.1 based on RC1

2024-01-08 Thread Mark Roberts

+1
Built with JDK 17.0.9 and passed BCEL tests.
Then integrated with Daikon and ran all our acceptance tests without error.
Mark

-Original Message-
From: Gary Gregory 
Sent: Sunday, January 7, 2024 12:20 PM
To: Commons Developers List 
Subject: [VOTE] Release Apache Commons BCEL 6.8.1 based on RC1

We have fixed BCEL-370 for SpotBugs and added some enhancements since Apache
Commons BCEL 6.8.0 was released, so I would like to release Apache Commons
BCEL 6.8.1.

Apache Commons BCEL 6.8.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.1-RC1 (svn
revision 66459)

The Git tag commons-bcel-6.8.1-RC1 commit for this RC is
6785009095d66a4a2bc01e64d25de987847eb114 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=6785009095d66a4a2bc01e64d25de987847eb114
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
--branch commons-bcel-6.8.1-RC1 commons-bcel-6.8.1-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1685/org/apache/bcel/bcel/6.8.1/

These are the artifacts and their hashes:

#Release SHA-512s
#Sun Jan 07 20:05:28 UTC 2024
bcel-6.8.1-bin.tar.gz=137eefdeb8921bd2b82f24d560fe73aeaea7af77eb2db0b84b321159cc737490fbca709402094d8f54ca4921944608b1e54cfe3caa72c96ced8d65ffa23eb10d
bcel-6.8.1-bin.zip=418ad7bd2f1f0d7176b0f4e9d64964ed7e3d486599db55b3ffa112948ace111e1372a5d406df5746f384f54edba58df9fd1022eb522c845ab64c7eae5551b9f8
bcel-6.8.1-bom.json=679d5be5ab9aafc51bac9ac72f86d17c39c9a62237fd3fcebc25cda40001d753dd98db2578df8c992f4a156c6ebd514bf686a5a32a6da55034f9ebbca5cccd8e
bcel-6.8.1-bom.xml=9a6d1d5eb3debd0cd23a4d8a46885ef55f4b16ea86042a3d3c4f6d19ea83e5039a1c94a27dcb1ae23091a0bff4e5ede652b8701d4cca9d6cfa925a0073ad6c60
bcel-6.8.1-javadoc.jar=eee243d6898d3ddd78c0edafef2d3e120886aae2b1f60bc8e825e8f39c3008f4184563349e6f354b04bd3198ada34e66bacd793f1fd2b987a880497dad7566f1
bcel-6.8.1-sources.jar=7af00081e0180f84d70c732b6099cefe2fd3f07bd13a697e471a9d7f7af29f31580d3f1271645b8e58d583bf5c13587fcfe9f2df81334a20c90314c1bd876a35
bcel-6.8.1-src.tar.gz=1a38f4603bfe8692e4fc71a911fbb37ddc30ee5afa270d4b36f0325879a555df2cab34e2abf38645a3c7b780e30dec516a0eac21a0d7e18ff412a5762282360e
bcel-6.8.1-src.zip=f6d4c953cf64995fc96c7c34c08e15ad1daad410c97db5efdf7acc1e70fa00f9c7c560aa9006fb10f46975268250663534fc45e635d25f090b2f4d3531a1c2a8
bcel-6.8.1-test-sources.jar=3114e0cbaee9ba42ba57c860a91574f3f36ceb018e71a24003443353b59763bb885160c75c886ffb2e703933b8dfa27e33a694bca39db7f51150f263964593da
bcel-6.8.1-tests.jar=1588bb81b339bc8f645335630ab31bf8df23776fd5757e4d608477e914feff15876bf3e2446c1ae28fb62cb71249da3c667298b543619e456468682dad14c938
org.apache.bcel_bcel-6.8.1.spdx.json=7df4647adfb7a15ca9c58ac5c852898e0513cd3b8701686e1ed29b2bf2edd1c6da44a3ee6e8f69b398861b05c2e0ad60fb6960d99e1e309cbe3fd142c922cb1b

I have tested this with:

mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
deploy

Using:

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /usr/local/Cellar/maven/3.9.6/libexec
Java version: 17.0.9, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.9/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x",
version: "14.2.1", arch: "x86_64", family: "mac"

Darwin  23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10 PST
2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64

Details of changes since 6.8.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.1-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.1-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.1-RC1/site/index.html
(note some *relative* links are broken and the 6.8.1 directories are not
yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 6.8.0):

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.1-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.1-RC1/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
--branch commons-bcel-6.8.1-RC1 commons-bcel-6.8.1-RC1 cd
commons-bcel-6.8.1-RC1

Re: [VOTE] Release Apache Commons BCEL 6.8.0 based on RC1

2023-12-03 Thread Mark Roberts

Issues I opened marked resolved fixed: 287, 294, 295, 296, 297, 329, 330,
333, 334, 335, 340
Issue I opened that has fix available: 361


On Sun, Dec 3, 2023 at 9:10 AM Elliotte Rusty Harold 
wrote:

> https://issues.apache.org/jira/projects/BCEL/issues/BCEL-337 looks
> like it's fixed and should be closed prior to release. Might be worth
> doing a quick pass through the issue tracker to see if there's
> anything else in there that needs to be closed or addressed.
>
> On Sun, Dec 3, 2023 at 4:33 PM Gary Gregory 
> wrote:
> >
> > We have fixed a few bugs and added some enhancements since Apache
> > Commons BCEL 6.7.0 was released, so I would like to release Apache
> > Commons BCEL 6.8.0.
> >
> > Apache Commons BCEL 6.8.0 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1 (svn
> > revision 65804)
> >
> > The Git tag commons-bcel-6.8.0-RC1 commit for this RC is
> > cf6f7e710abf4eda2e0aa9aa914aa17878999583 which you can browse here:
> >
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=cf6f7e710abf4eda2e0aa9aa914aa17878999583
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > --branch commons-bcel-6.8.0-RC1 commons-bcel-6.8.0-RC1
> >
> > Maven artifacts are here:
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1678/org/apache/bcel/bcel/6.8.0/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Sun Dec 03 11:17:12 EST 2023
> >
> bcel-6.8.0-bin.tar.gz=955d66a5a34d25c90c71273467a2f876f3b3fb3437fc533f7a7583ea0390474817aefbb9a9b4190973011ad053e145c9c0bac42832f8198b562e693a25b2803f
> >
> bcel-6.8.0-bin.zip=04e5fe2830127add83108de8df61aab185e38a5117dddfa348533260b5d355da1fb0db56b0b5361e680308d2feea6a3b04acc99d6a93b9ad2dfdb943893cb583
> >
> bcel-6.8.0-bom.json=1555e608b267a74adc10938377f8eb60f1b2fa477c1834582ded805530d3cf676ac14d6f1966bdd5d9ccef4cc9f2a32ff1ce6d9b6963fc1d288f8263585b639f
> >
> bcel-6.8.0-bom.xml=e1bb499766046147619dd1f1443089b043ee11bf09234c19f14b15261ae54e186c51bd2f7f9f622a71dac1d6a6712bef4c504bd21e975550bef6cfe886c607ba
> >
> bcel-6.8.0-javadoc.jar=5fdaa3d79e57a6fcff8e3dfd9295e4681d3f7b35ae6f248b6bee292e46f0f7cff6b80a88f198c6eed6a966be1e59d272e68f3d8dd39cee0b48ce8920e4ef7495
> >
> bcel-6.8.0-sources.jar=a55973bc87409c525860709ff94055808cb46ce13f236f5a119e763ee4a024b9c0c3ac78c80c6e8489f6fc9c535aff8468f09a796889d5dc5c4f9dd593bb337e
> >
> bcel-6.8.0-src.tar.gz=fcec4920f841b9b22b7fe05190ed09a31e2edd32dbc9bc6217981af34fecab0725249bbaf0e5810e0c7ef8a347dbe07fa1dfc1a80a7b651368ad4ea852f54f6e
> >
> bcel-6.8.0-src.zip=4d7c00f9400b206db48823a77cb09bbb2b25074108e8980c84c701d6b73f77290cf3bed56e392d270c8e084d7c2306ac3fb9b4a4f7f1e6cb883b683f7b3d972e
> >
> bcel-6.8.0-test-sources.jar=8924279acde0fc8d101cc27b9e69b514b98a69793c990cadaae193da0fe5913630b99ebfd10568a3baa5e79bd4d93f8020202accf12a6a0e14ef07deb31736db
> >
> bcel-6.8.0-tests.jar=4d7715acb6d38d50f8a9e4cbef232190fd3d7efaf54ade772d677e129c89af69a528a1bff6dae6300058f2e1c1393acf18a554c85ac0a6f6d95f0aad4680426c
> >
> org.apache.bcel_bcel-6.8.0.spdx.json=dc47d97c197e3e0ce124b7f3a03e74552b6764e46195058d47daca19a597fb49469119115a58e7f3dc951cb851c031e60840e09d94632c4687332049dc305c10
> >
> > I have tested this with:
> >
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> deploy
> >
> > Using:
> >
> > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > Maven home: /usr/local/Cellar/maven/3.9.6/libexec
> > Java version: 21.0.1, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac"
> >
> > Darwin  23.1.0 Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:27
> > PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64
> >
> > Details of changes since 6.7.0 are in the release notes:
> >
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1/RELEASE-NOTES.txt
> >
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1/site/changes-report.html
> >
> > Site:
> >
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1/site/index.html
> > (note some *relative* links are broken and the 6.8.0 directories
> > are not yet created - these will be OK once the site is deployed.)
> >
> > JApiCmp Report (compared to 6.7.0):
> >
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1/site/japicmp.html
> >
> > Note that the above report notes one issue:
> > MODIFIED (Serializable incompatible(!): field changed from
> > nontransient to transient) public class
> > org.apache.bcel.util.ClassVector
> > Note that a java.util.List of org.apache.bcel.classfile.JavaClass
> > is not serializable in the first place because JavaClass is not
> > serializable.
> >
> > RAT Report:
> >
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.8.0-RC1/site/rat-report.html

repo usage question

2022-12-28 Thread Mark Roberts

What is the difference/preferred usage between
github.com/apache/commons-bcel and
gitbox.apache.org/repos/asf/commons-bcel.git?

Thanks,
Mark

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

RE: [BCEL] Invalid test or bug?

2022-11-17 Thread Mark Roberts

I will try to take a look at this later today.

Mark

-Original Message-
From: Gary D. Gregory [mailto:ggreg...@apache.org]
Sent: Thursday, November 17, 2022 7:14 AM
To: dev@commons.apache.org
Subject: Re: [BCEL] Invalid test or bug?

More specifically, javap says:

21: invokevirtual #68 // Method
"[B".clone:()Ljava/lang/Object;

So calling a method on an array with invokevirtual is ok and we have a bug.

Thoughts?

Gary

On 2022/11/17 14:45:41 "Gary D. Gregory" wrote:
> Hm, I'm thinking bug when I see javap output like:
>
> #68 = Methodref  #901.#902//
> "[B".clone:()Ljava/lang/Object;
>
> Thoughts?
>
> Gary
>
> On 2022/11/17 13:04:32 "Gary D. Gregory" wrote:
> > Actually: VerifyJavaMathTestCase and VerifyJavaUtilTestCase
> >
> > Gary
> >
> > On 2022/11/17 13:00:21 "Gary D. Gregory" wrote:
> > > Hi All & Mark Roberts:
> > >
> > > I added JavaMathTestCase as a disabled test as it fails.
> > >
> > > Is this a legal test to try or do we have a bug?
> > >
> > > Gary
> > >
> > > --
> > > --- 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
> >
> >
>
> -
> 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

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

RE: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

2022-11-02 Thread Mark Roberts

In the constructor of
/src/main/java/org/apache/bcel/verifier/structurals/ExceptionHandlers.java -
the 'computeIfAbsent' line is duplicated.  Is this correct?

Mark

-Original Message-
From: Gary D. Gregory [mailto:ggreg...@apache.org]
Sent: Tuesday, November 1, 2022 10:17 AM
To: dev@commons.apache.org
Subject: Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC2

ping :-)

On 2022/10/29 16:35:28 Gary Gregory wrote:
> We have fixed a regression bug since Apache Commons BCEL 6.6.0 was
> released, so I would like to release Apache Commons BCEL 6.6.1.
>
> Apache Commons BCEL 6.6.1 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2 (svn
> revision 57656)
>
> The Git tag commons-bcel-6.6.1-RC2 commit for this RC is
> eda94276de5d01c81e73ab2f165a49e841c7b69f which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=eda9
> 4276de5d01c81e73ab2f165a49e841c7b69f
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> --branch
> commons-bcel-6.6.1-RC2 commons-bcel-6.6.1-RC2
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-16
> 05/org/apache/bcel/bcel/6.6.1/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Oct 29 12:22:19 EDT 2022
> Apache\ Commons\
> BCEL-6.6.1.spdx.rdf.xml=4f97b219f60290e0795999cf3c3483d2738dd429ca013f
> 764b20078a6f799200ff958a14cb4cc03c73f30b58836bf59229ce6ee4f5e94022df8b
> 533000946c84
> bcel-6.6.1-bin.tar.gz=7826733c3d139e52b6022d5df7430c391bd3b93707ef99f5
> 803390cb91f4ba0b87b073ca4e208869c5bd453f40739631ad8d6ab5ed3cbbc9270a5d
> c0345238f4
> bcel-6.6.1-bin.zip=d1c2fca54a5d5acc8edae097a7383dd56eb324a73f343da901b
> 0b1ea50b6a01910674e2f7f4497e8ac299fef25afb0060399c3aadbbabb879356f6fb0
> b4389ad
> bcel-6.6.1-bom.json=fb408f3f439fd0dcaef0ca6b2bf309bc6aac523096a12f7e5b
> af6374fa05f7d9f919b0ce520ceaf08b51960d8483f638d4e2ce5bd0994168786354bf
> 02866dd4
> bcel-6.6.1-bom.xml=7ef7417e5ef7f4443b4faba6cbc0c32b88522cf359d5de9a50e
> ad505070bb7ef779a18c9cad0aeaab6cf458f7c700ca3548a63f7d0a2804f73a527299
> 9f62855
> bcel-6.6.1-javadoc.jar=9a58c07addcb18f4a567418abf9e8d75e17ba6f05de0f95
> 6797890bfb4d1d8a8403d03f8cf947b4f48d9fc8c98276befb9fb2060e526dfd44e96e
> e3e755047e0
> bcel-6.6.1-sources.jar=6de8e778b0e82b3004c3d6041fa451ccf4a3a10ec61d1ff
> b1cf39287ea49440018d9d3ba06acad6de6e2b3cfd9d58737f5696ed8b20b3ba9ab5fd
> 642e7ae2aac
> bcel-6.6.1-src.tar.gz=d746bee8f0c3483fe589845a1a843043e6162970751e1e21
> a30f01f122556a1b9d52a8c7d808db91671f0f2324ff871ba5f571fc369bb77d232680
> 654cbb77b4
> bcel-6.6.1-src.zip=6759324529a42e45ffdd449cddf01dade57459b86a4820550d5
> a859ff1eca85057a9343ae217def029d9f8e4b3365b49f692522a2e75cd1dc4806b8f9
> 09c613a
> bcel-6.6.1-test-sources.jar=604df990454feb5976b9f0b763bdbd50a434bb1db2
> 6d9876a555195ca42d99a3b6b84b2718ac925896a9bb2c05f0633d4cb275fe69574183
> 6fe9aa0cb18d4db3
> bcel-6.6.1-tests.jar=0f1b1396d376cc0f2c69e897817b0a7b24db282cf7122d895
> dabe70aa1b7d0faf4348cae4cb01e4d93224552f4db77fdd86af11c69574635b282e74
> b451a689e
>
>
> I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease
> -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using:
>
> Darwin  21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10
> PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64 Apache Maven
> 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_345, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+345/libexec/openjdk.jdk/Contents/Hom
> e/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os
> x", version: "12.6", arch: "x86_64", family: "mac"
>
> Details of changes since 6.6.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/RELEASE-
> NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/cha
> nges-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/index.html
> (note some *relative* links are broken and the 6.6.1 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 6.6.0):
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/jap
> icmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC2/site/rat
> -report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key 86fdc7e2a11262cb)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
>

RE: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC1

2022-10-26 Thread Mark Roberts

I think a camelCase edit was missed in classfile/FieldOrMethod.java.  The
method 'copy_' has constantPool in the arg list and constant_pool in the
body. constant_pool is class field and I don’t think the intention of copy_
is to reuse the existing ConstantPool.

Mark


-Original Message-
From: Gary D. Gregory [mailto:ggreg...@apache.org]
Sent: Tuesday, October 25, 2022 4:37 AM
To: dev@commons.apache.org
Subject: Re: [VOTE] Release Apache Commons BCEL 6.6.1 based on RC1

Ping ;-)

On 2022/10/23 14:58:05 Gary Gregory wrote:
> We have fixed one bug since Apache Commons BCEL 6.6.0 was released, so
> I would like to release Apache Commons BCEL 6.6.1. This will help
> SpotBugs migrate from 6.5.0.
>
> Apache Commons BCEL 6.6.1 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC1 (svn
> revision 57519)
>
> The Git tag commons-bcel-6.6.1-RC1 commit for this RC is
> ec208052baf4c596f7e8cfacc281d3e2408809ac which you can browse here:
>
> https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=ec20
> 8052baf4c596f7e8cfacc281d3e2408809ac
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> --branch commons-bcel-6.6.1-RC1 commons-bcel-6.6.1-RC1
>
> Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-16
> 02/org/apache/bcel/bcel/6.6.1/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sun Oct 23 10:44:36 EDT 2022
> Apache\ Commons\
> BCEL-6.6.1.spdx.rdf.xml=f07a9526a013c6c700e84005f45eb3f582b105756486b6
> 65b084be1accf147179e22db752c370dd2cf2c779a2c9188b2fec431fc7de56f0cfc35
> 5c26ea25d2fe
> bcel-6.6.1-bin.tar.gz=4358ab0a7103e33bf4d0774cdeab11c4b32a7ef65944e086
> 02b6a5c2da7ac1e8f04edc1603b458381e29c9341c32f1679521bb544eb4a081c351d8
> 2b646d6024
> bcel-6.6.1-bin.zip=1acd0c776c06d50e7f2a4c5d6f7ea90374cdb9f0d6ddc994eb5
> d8a6eb3632ac10327167b372567456b0b83c0ebd99652f0f69c39e3ba57d31b87b3206
> 3eb223d
> bcel-6.6.1-bom.json=e51e003589f1de2e73d1fbc3dfdff6f30e85df2aca036b9bcd
> f5dffe5eb6915adbbb8ab72aed63ff5dcd32b9db51316a088c2b89e8ad54657170c21f
> eae404a8
> bcel-6.6.1-bom.xml=f00ddbf5a93d88209e781a71de7067897005e36ca88d5be10f1
> 05af87f8ae7cabe07e6373f166def2de4c7d72b30e25e8f20a6f17827260754ed87048
> 0647049
> bcel-6.6.1-javadoc.jar=35d2dc3daaa7adefd17561f4dc896dbdce5fb0530c8d867
> fc8178bdab8c9d21afd27b4429b9650281d8692a62039739795b642e9ff5c317a73b10
> 89661aab491
> bcel-6.6.1-sources.jar=3ecf109550cd8837dba586570e33c73fa81efccc69e2b68
> cc03b53756947e4c9f95575e77b751181cf934f20f5e078654f343400b8184ab414e89
> b316f7f33f4
> bcel-6.6.1-src.tar.gz=bb4283d1ebcdeaef7f3530826f16681cad7a53508056178d
> 63621f7a17321df3bbc11914e75dd7b81f967723c8b6bc4009853dc80bb4707de2f5f6
> db26eb8f7a
> bcel-6.6.1-src.zip=a62790a65ecb2f69f260f683d9f75a3a4ef98abfbec5a37efbe
> 10ad7d5fd9c33771ff5cba305c3f18c336f8495a1ce5c5ab43ecb9124973e2728742d6
> 34b6288
> bcel-6.6.1-test-sources.jar=0f4dd1c7652b564b1343cc2731118c3575d351022f
> 2811d3049f9eccda77b9fb05779691996ddb6396717fa75699e8a407f5c654bf75d5a7
> aca50bd1a2e9d95f
> bcel-6.6.1-tests.jar=1a06e51f00d8de83c4128ddfaf3a318a2afca8e5e67739cfb
> 05956d4c4fce02028d3a93ca3288fc494b46ca08d6e707544b5cc5401c12396cde4a0d
> c25d49136
>
> I have tested this with 'mvn' (the default goal) and 'mvn -V
> -Duser.name=$my_apache_id -Prelease -Ptest-deploy -P jacoco -P japicmp
> clean package site deploy' using:
>
> Darwin  21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10
> PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64 Apache Maven
> 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_345, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+345/libexec/openjdk.jdk/Contents/Hom
> e/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os
> x", version: "12.6", arch: "x86_64", family: "mac"
>
> Details of changes since 6.6.0 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC1/RELEASE-NOTES.txt
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC1/site/cha
> nges-report.html
>
> Site:
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC1/site/index.html
> (note some *relative* links are broken and the 6.6.1 directories
> are not yet created - these will be OK once the site is deployed.)
>
> JApiCmp Report (compared to 6.6.0):
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC1/site/jap
> icmp.html
>
> RAT Report:
>
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.1-RC1/site/rat
> -report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release

RE: [VOTE] Release Apache Commons BCEL 6.6.0 based on RC1

2022-10-11 Thread Mark Roberts

+1

Tested via integration with Daikon tool set.  Passed all build and
acceptance tests.

Mark Roberts


-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Saturday, October 8, 2022 5:36 AM
To: Commons Developers List 
Subject: [VOTE] Release Apache Commons BCEL 6.6.0 based on RC1

We have fixed a few bugs and added some enhancements since Apache Commons
BCEL 6.5.0 was released, so I would like to release Apache Commons BCEL
6.6.0.

Apache Commons BCEL 6.6.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.0-RC1 (svn
revision 57228)

The Git tag commons-bcel-6.6.0-RC1 commit for this RC is
78ecfd5a76ab24e9cb3e5fab6bd4f60187cd6342 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=78ecfd5a76ab24e9cb3e5fab6bd4f60187cd6342
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
--branch commons-bcel-6.6.0-RC1 commons-bcel-6.6.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1599/org/apache/bcel/bcel/6.6.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Oct 08 08:08:18 EDT 2022
Apache\ Commons\
BCEL-6.6.0.spdx.rdf.xml=f7124616f821975c0ff263bf7a140d5289255a9411c0455504b031afe274b45690e906eb2e33a2948d2842bdd0dc053ac3ed8610620144b410b6cd40c0292a5e
bcel-6.6.0-bin.tar.gz=444b0f80e8729ba88219ed73aaf79f51f86233dee1213823c9e511392b608b6b64304d161d58d5d8c5070dd976a2a1b26866023b89db4d0883d9325790ab
bcel-6.6.0-bin.zip=b9652fbe2ff847aae43789cc2fbb3610f48de585f03e022e1251b811931cc86ffb0015295da06c3c129eed67890baf164eb90b41d0f9e0ffc98321c14538de1e
bcel-6.6.0-bom.json=8e49ec6054792b71b17f17899ee6f73a62ba2748b6aaf2753f01759f52b477dbb4f1894009cc6ca562f40956c8361ad76490dd3f1263d65791ce5ab75b0a8def
bcel-6.6.0-bom.xml=dde502c23f2573c321ecbc15cebec2f4646f1d0b68e91db9d7ffbe7ec5e840aeb8094d77ddd04898a41bfee96381c219c7721e0cb3b47508bf89de81931d191e
bcel-6.6.0-javadoc.jar=4efa4c85df233c84262dfc02bb5cd8738e22c31e4bf4979dc17fbe6e9416001e2dc2b87321f89eff5de88da5f977bc52439a2b268865058c8af40d486177aa6e
bcel-6.6.0-sources.jar=69a677bebb80bce9e87a95d2d97115157613383a096985530ef744780418a62494c6586b5a0b7d82c19919d3edd76de57b4baea87355b5d07d9db925763c7d35
bcel-6.6.0-src.tar.gz=13f361be498625c3276860ae14c225c49135687f4ba69de4afaac2d135df4e5c6b51277e3cd4c05bac27156e4fab5316c102a25a67d8abb6c640499917d01917
bcel-6.6.0-src.zip=097b26494758f2a4db2f3d91f199cf02d1d8209022e6e93416e54cdcae94f7b0866169db631ad60d9c4c309fba5cf3aec06d7ca88e33486ddca43fe29707984b
bcel-6.6.0-test-sources.jar=b9d4452afa720afb8bcb944e8b2f12791a2f6e2034ca08d5c19b7f57b44ab4d26e5eedaa36af008e24fc0663adbba3e05d86b88af50bcd6f3aacc4f1bbbc8d56
bcel-6.6.0-tests.jar=0221fff1f00d38b0e73f8b25c7fdebfec74ae28936c3b4c52a463a70292a1acc0d027452a38e854d0434673f16c10c0ba69841ad0ce02d1de57d1b5db0c1388e


I have tested this with
'mvn -V -Duser.name=$my_apache_id -Prelease -Ptest-deploy -P jacoco -P
japicmp clean package site deploy' using:

Darwin *** 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT
2022; root:xnu-8020.140.49~2/RELEASE_X86_64 x86_64 Apache Maven 3.8.6
(84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/Cellar/maven/3.8.6/libexec
Java version: 1.8.0_345, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@8/1.8.0+345/libexec/openjdk.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x",
version: "12.6", arch: "x86_64", family: "mac"

Details of changes since 6.5.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.0-RC1/site/index.html
(note some *relative* links are broken and the 6.6.0 directories are not
yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 6.5.0):

https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.6.0-RC1/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
--branch c

RE: BCEL: Can't load Object.class using LDC

2022-02-04 Thread Mark Roberts

I would suggest defaulting to the system property "java.version", that is
what the Daikon tool set does.

Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Friday, February 4, 2022 7:54 AM
To: Commons Developers List 
Subject: Re: BCEL: Can't load Object.class using LDC

Stefan,

Would you please create a Jira ticket? This will give your issue more
visibility and one location with ALL the information needed in the future.

Gary


On Fri, Feb 4, 2022, 09:49 Stefan Reich
 wrote:

> Will you look at that. BCEL's verifier actually checks for this
> (Pass3aVerifier.java):
>
> public void visitLDC(final LDC ldc) {
> indexValid(ldc, ldc.getIndex());
> final Constant c = constantPoolGen.getConstant(ldc.getIndex());
> if (c instanceof ConstantClass) {
>   addMessage("Operand of LDC or LDC_W is CONSTANT_Class '"+c+"' -
> this is only supported in JDK 1.5 and higher.");
> }
> else{
>   if (! ( c instanceof ConstantInteger||
>   c instanceof ConstantFloat ||
> c instanceof ConstantString ) ) {
> constraintViolated(ldc,
> "Operand of LDC or LDC_W must be one of CONSTANT_Integer,
> CONSTANT_Float or CONSTANT_String, but is '"+c+"'.");
>   }
> }
> }
>
> It generates just a warning though, not an actual error.
>
> I quickly checked out LDC.java to see if I can submit a PR, but I
> think I don't know enough about BCEL to actually do it. I'll leave it
> to the experts.
>
> Greetings
>
> On Fri, 4 Feb 2022 at 15:37, Stefan Reich <
> stefan.reich.maker.of@googlemail.com> wrote:
>
> > Update: They changed it in Java 5. ClassGen.setMajor(49) +
> > ClassGen.setMinor(0) works.
> >
> > On Fri, 4 Feb 2022 at 15:26, Stefan Reich <
> > stefan.reich.maker.of@googlemail.com> wrote:
> >
> >> Mystery solved, ladies and gentlemen...
> >>
> >> It was...
> >>
> >> the byte code version. BCEL outputs version 45.3 by default (JDK 1.1).
> >> There were multiple changes to the class file format spec since then.
> >>
> >> Specifically, they must have allowed ldc to load .class objects
> >> directly at some point after JDK 1.1. In fact, I distinctly
> >> remember the Class.forName shenanigans that javac produced back
> >> then instead of the direct ldc.
> >>
> >> Apparently the Java verifier is so strict it judges the class file
> >> according to its version number and disallows the new version of
> >> ldc in
> a
> >> class file written for JDK 1.1.
> >>
> >> BCEL doesn't check for this though and outputs a broken class file.
> >> Changing this might be a good idea.
> >>
> >> Unfortunately I couldn't find documentation on when the byte code
> >> spec change happened. Does anyone know?
> >>
> >> Neither did I find anything in the HotSpot verifier sources <
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile
> /verifier.cpp
> >
> >> which is odd to me. No mention of a JDK version there. Only in
> >> clasfileparser.cpp <
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile
> /classFileParser.cpp
> >
> >> but didn't find the issue in question there either. I'm by no means an
> >> expert in the JDK C++ source though.
> >>
> >> Cheers
> >> Stefan
> >>
> >> On Thu, 3 Feb 2022 at 08:32, Romain Manni-Bucau 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Maybe a bit ot of topic but did you check with asm (using classreader
> for
> >>> ex) if it is readable for it? Javap in verbose mode is hard to read
> >>> humanly
> >>> (and not verbosel does not mean much) so an issue can still be hidden.
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >>> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>> >
> >>>
> >>>
> >>> Le jeu. 3 févr. 2022 à 01:42, Stefan Reich
> >>>  a écrit :
> >>>
> >>> > I'm mainly curious how it's possible that everything looks
> >>> > completely
> >>> > normal in javap (checked a dozen times), but the class verifier
> >>> complains
> >>> > anyway? Something has to be different. Is there a way to dig deeper
> >>> into a
> >>> > class file?
> >>> >
> >>> > Greetings
> >>> >
> >>> > On Wed, 2 Feb 2022 at 23:14, Stefan Reich <
> >>> > stefan.reich.maker.of@googlemail.com> wrote:
> >>> >
> >>> > > Hmm, no change with latest version.
> >>> > >
> >>> > > I did "git clone https://github.com/apache/commons-bcel.git; and
> >>> "mvn
> >>> > > package".
> >>> > >
> >>> > > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ javac -cp
> >>> > > bcel-6.6.0-SNAPSHOT.jar MakeBadClassFile.java
> >>> > > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java -cp
> >>> > > bcel-6.6.0-SNAPSHOT.jar:. MakeBadClassFile
> >>> > > Now please try: java BadClassFile
> >>> > >

RE: [VOTE] Release Apache Commons BCEL 6.5.0 based on RC1

2020-06-06 Thread Mark Roberts

I ran all my tests with Java 8 and Java 11 - looks good.
+1

Mark

-Original Message-
From: Gary Gregory [mailto:ggreg...@apache.org]
Sent: Friday, June 5, 2020 3:03 PM
To: Commons Developers List
Subject: [VOTE] Release Apache Commons BCEL 6.5.0 based on RC1

We have fixed a few bugs and added some enhancements since Apache Commons
BCEL 6.4.1 was released, so I would like to release Apache Commons BCEL
6.5.0.

Apache Commons BCEL 6.5.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1 (svn
revision 39954)

The Git tag commons-bcel-6.5.0-RC1 commit for this RC is
a9c13ede0e565fae0593c1fde3b774d93abf3f71 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=a9c13ede0e565fae0593c1fde3b774d93abf3f71
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
commons-bcel-6.5.0-RC1 commons-bcel-6.5.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1499/org/apache/bcel/bcel/6.5.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Fri Jun 05 17:50:12 EDT 2020
bcel-6.5.0-bin.tar.gz=a97eb0b8c39ec96cf15168cc38d51065d4c3223729069bdf86ace61970124d73cee4b5ccfae605d0184c3154247abd382fc59241cecafb678532237167631212
bcel-6.5.0-bin.zip=683f89e3c365d95882ca6d4d68408f578f25a5f5fda5af732cab175b29558b8d8c0a97aaa7d3026ba645d54160095dcda048ee12232f5a3f03e1293dd6621f20
bcel-6.5.0-javadoc.jar=c82e46d666b04035b313ccf99e2e513bd02740c1c90d5cf0e02e00b819382525a1a793da72f3519a706ea189d5b163c72cf4d4a2feed6b74a47d756a912e905d
bcel-6.5.0-sources.jar=2917b32067cd8c76b1691df8e882cf10be0fe6328e366c0d335e0f5e85d861a612577b1d9fbb2e6980a8fceb618f80abf8c1c80aa350c9e4a7166d4c2fb056dd
bcel-6.5.0-src.tar.gz=c6da4b4d4cbad3ad2b3a4c0208063e3858170356fc4f6670c95ce819f0aea69f103914875a12bf2715a869c2b19a3e79fcb55a695eb269d9937520db25da1e3d
bcel-6.5.0-src.zip=45642eb5e93da9da7252f17a0e58ee17c952b569e86d398353daa2a0bf4846a34ea79acd3329fa317814e15706e9993d4529c217476734918b97e1adb2ea7773
bcel-6.5.0-test-sources.jar=aed90e44f7e49e2ea39e945a55aa2bf28b7c87685afea0c68d3e83f1acb5488290d70d2b18f62a89bf31509f226ee3c46811e608b7bca447edeceb83bdee3a4d
bcel-6.5.0-tests.jar=2b7dfef01c8f885e351590267c5236c6512658ddb70ab80ca1fb5b9035e4176a410f76dc22199959a2343c03917fc30d1fe6d35715cc3bae550a8021f0ea7e57

I have tested this with
'mvn -V -Duser.name=%my_apache_id%
-Dcommons.release-plugin.version=%commons.release-plugin.version%
 -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy'
using:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: C:\Java\apache-maven-3.6.3\bin\..
Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_251\jre Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Details of changes since 6.4.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/changes-report.html

Site:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/index.html
(note some *relative* links are broken and the 6.5.0 directories are not
yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 6.4.1):

https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/bcel/6.5.0-RC1/site/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

For following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-bcel.git --branch
commons-bcel-6.5.0-RC1 commons-bcel-6.5.0-RC1 cd commons-bcel-6.5.0-RC1

2) Check Apache licenses

This step is not required if the site includes a RAT report page which you
then must check.

mvn apache-rat:check

3) Check binary compatibility

Older components still use Apache Clirr:

This step is not required if the site includes a Clirr report page which you
then must check.

mvn clirr:check

Newer components use JApiCmp with the japicmp Maven Profile:

This step is not required if the site includes a JApiCmp report page which
you then must check.

mvn install -DskipTests -P japicmp japicmp:cmp

4) Build the package

mvn -V clean package

You can record the

RE: [bcel] Anything pending for a 6.4.2 release?

2020-06-01 Thread Mark Roberts

It’s the other way around - it was protected in 6.4.1 and we need it to be 
public or else there is no way to manipulate annotations.  Without that we're 
dead.

Mark

(There was never a pr because I could never get anybody to say it was okay. )

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Monday, June 1, 2020 6:46 PM
To: Commons Developers List 
Subject: Re: [bcel] Anything pending for a 6.4.2 release?

If something is public in 6.4.1, we cannot change that. Basically, we cannot 
break BC.

Gary


On Mon, Jun 1, 2020 at 9:44 PM Gary Gregory  wrote:

> Did I miss a PR? I do not see an open PR from you.
>
> Gary
>
> On Mon, Jun 1, 2020 at 7:54 PM Mark Roberts 
> wrote:
>
>> I'm happy to do that - but what about my requested changes to 
>> src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java?
>>
>> 123c123
>> < protected void addAnnotationEntry(final AnnotationEntryGen ag) //
>> TODO
>> could this be package protected?
>> ---
>> > public void addAnnotationEntry(final AnnotationEntryGen ag) // 
>> > TODO could this be package protected?
>> 139c139
>> < protected void removeAnnotationEntry(final AnnotationEntryGen ag) //
>> TODO could this be package protected?
>> ---
>> > public void removeAnnotationEntry(final AnnotationEntryGen ag) 
>> > //
>> TODO
>> > could this be package protected?
>> 155c155
>> < protected void removeAnnotationEntries() // TODO could this be
>> package
>> protected?
>> ---
>> > public void removeAnnotationEntries() // TODO could this be 
>> > package protected?
>>
>> -Original Message-
>> From: Gary Gregory [mailto:garydgreg...@gmail.com]
>> Sent: Monday, June 1, 2020 4:30 PM
>> To: Commons Developers List
>> Subject: Re: [bcel] Anything pending for a 6.4.2 release?
>>
>> Hi Mark,
>>
>> May you please try the latest from git master and see how that goes? 
>> I've merged PR 39 and 40.
>>
>> Gary
>>
>>
>> On Mon, Jun 1, 2020 at 5:15 PM Mark Roberts 
>> 
>> wrote:
>>
>> > In order to support Java 11 in our tools set we needed to update BCEL.
>> > Hence, we made a private release (marked as version 6.4.2) that 
>> > contained the following changes:
>> >
>> > Issue 333 - pull request 39
>> > Issue 334 - pull request 40
>> > Made AnnotationEntry methods public instead of protected.
>> >
>> > I sent at least two rounds of email on the latter item, the most 
>> > recent in February of this year which drew no response.
>> >
>> > We would really like to see these three changes in an official 6.4.2.
>> >
>> > Thank you,
>> > Mark Roberts
>> >
>> >
>> >
>> > -Original Message-
>> > From: Gary Gregory [mailto:garydgreg...@gmail.com]
>> > Sent: Saturday, May 30, 2020 7:23 AM
>> > To: Commons Developers List
>> > Subject: [bcel] Anything pending for a 6.4.2 release?
>> >
>> > Mark and all:
>> >
>> > I see a few fixes in git master for the 6.4.2 release. Is there 
>> > anything else?
>> >
>> > I am just taking stock of some components what could be useful to
>> release.
>> >
>> > Gary
>> >
>> > ---
>> > -- 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
>>
>>


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

RE: [bcel] Anything pending for a 6.4.2 release?

2020-06-01 Thread Mark Roberts

I'm happy to do that - but what about my requested changes to
src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java?

123c123
< protected void addAnnotationEntry(final AnnotationEntryGen ag) // TODO
could this be package protected?
---
> public void addAnnotationEntry(final AnnotationEntryGen ag) // TODO
> could this be package protected?
139c139
< protected void removeAnnotationEntry(final AnnotationEntryGen ag) //
TODO could this be package protected?
---
> public void removeAnnotationEntry(final AnnotationEntryGen ag) // TODO
> could this be package protected?
155c155
< protected void removeAnnotationEntries() // TODO could this be package
protected?
---
> public void removeAnnotationEntries() // TODO could this be package
> protected?

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Monday, June 1, 2020 4:30 PM
To: Commons Developers List
Subject: Re: [bcel] Anything pending for a 6.4.2 release?

Hi Mark,

May you please try the latest from git master and see how that goes? I've
merged PR 39 and 40.

Gary


On Mon, Jun 1, 2020 at 5:15 PM Mark Roberts 
wrote:

> In order to support Java 11 in our tools set we needed to update BCEL.
> Hence, we made a private release (marked as version 6.4.2) that
> contained the following changes:
>
> Issue 333 - pull request 39
> Issue 334 - pull request 40
> Made AnnotationEntry methods public instead of protected.
>
> I sent at least two rounds of email on the latter item, the most
> recent in February of this year which drew no response.
>
> We would really like to see these three changes in an official 6.4.2.
>
> Thank you,
> Mark Roberts
>
>
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Saturday, May 30, 2020 7:23 AM
> To: Commons Developers List
> Subject: [bcel] Anything pending for a 6.4.2 release?
>
> Mark and all:
>
> I see a few fixes in git master for the 6.4.2 release. Is there
> anything else?
>
> I am just taking stock of some components what could be useful to release.
>
> Gary
>
> -
> 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] Anything pending for a 6.4.2 release?

2020-06-01 Thread Mark Roberts

In order to support Java 11 in our tools set we needed to update BCEL.
Hence, we made a private release (marked as version 6.4.2) that contained
the following changes:

Issue 333 - pull request 39
Issue 334 - pull request 40
Made AnnotationEntry methods public instead of protected.

I sent at least two rounds of email on the latter item, the most recent in
February of this year which drew no response.

We would really like to see these three changes in an official 6.4.2.

Thank you,
Mark Roberts



-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Saturday, May 30, 2020 7:23 AM
To: Commons Developers List
Subject: [bcel] Anything pending for a 6.4.2 release?

Mark and all:

I see a few fixes in git master for the 6.4.2 release. Is there anything
else?

I am just taking stock of some components what could be useful to release.

Gary

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

RE: strange change to src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java

2020-02-15 Thread Mark Roberts

I really would like to move forward with this.  If you look at the code in
src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java you will see:

Public addAttribute ...
Protected addAnnotationEntry ...
Public removeAttribute ...
Protected removeAnnotationEntry ...
Public removeAttributes ...
Protected remove AnnotationEntries ...

I would just like to change the protected to public so one can manipulate
annotations in the same manner as attributes.

Thank you,
Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com]
Sent: Friday, October 18, 2019 8:29 AM
To: Commons Developers List
Subject: Re: strange change to
src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java

Hi All:

The upshot here (to me) is that we have an opportunity to help Mark by:

- Simply agreeing that it is OK to change the visibility of the method(s) if
appropriate tests are added, or:
- Provide a new API _somewhere_, presumably in the _best/right_ place that
fulfills his app's needs.

The difference being changing visibility solely for expediency's sake vs.
thinking about the API and making sure provide this functionality in the
right place.

It seems that Mark can help us see it best since he's quite familiar with
the code by now.

Gary

On Fri, Oct 18, 2019 at 5:37 AM Emmanuel Bourg  wrote:

> Le 18/10/2019 à 11:10, Xeno Amess a écrit :
> > Do commons follow semver?
>
> No but we care about backward compatibility.
>
> Emmanuel Bourg
>
> -
> 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] Release 6.4.0

2019-10-21 Thread Mark Roberts

To respond to questions about changes to Annotation support, I am trying to 
review the current test coverage.  I ran the command line below.  I see a file 
named jacoco.exec  but that appears to be binary data.  Where do I find the 
code coverage report?

Thanks,

Mark

From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Friday, September 06, 2019 5:01 PM
To: Mark Roberts; Commons Developers List
Subject: Re: [BCEL] Release 6.4.0

Run:

mvn clean site -P jacoco

Then look at the generate site's JaCoCo report and make sure the new code has 
as close to possible to 100% code coverage by the unit tests.

The profile might not be required but it will make sure the right thing 
happens. 

Gary

On Fri, Sep 6, 2019, 19:58 Mark Roberts  wrote:

Sorry - not familiar with the release process.  What does check for code 
coverage mean?

mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Friday, September 6, 2019 3:09 PM
To: Commons Developers List 
Subject: Re: [BCEL] Release 6.4.0

I might have some time over the weekend. Would you mind double checking you 
recent work for code coverage.

Gary

On Fri, Sep 6, 2019, 09:07 Mark Roberts  wrote:

> I'm good.  From our standpoint it would be nice to make a BCEL release 
> so we don't need to include a special version with our tool set.
>
> Thanks,
> Mark
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Sunday, September 1, 2019 3:25 PM
> To: Commons Developers List 
> Subject: [BCEL] Release 6.4.0
>
> Hi All and Mark in particular,
>
> Is there anything more we need for 6.4.0?
>
> Gary
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

RE: strange change to src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java

2019-10-17 Thread Mark Roberts

So I'm forced to add pass through methods to MethodGen?  That seems a waste of 
effort and still requires testing.  I repeat - you can already manipulate 
Attrbiutes - you should be able to manipulate Annotations in exactly the same 
fashion.  It is a missing capability that is needed - at least by me and as we 
move forward into Java 9 and beyond I'm sure others are going to run the 
problem.

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Thursday, October 17, 2019 3:55 PM
To: Commons Developers List 
Subject: Re: strange change to 
src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java

On Thu, 17 Oct 2019 at 23:16, Mark Roberts  wrote:
>
> When the BCEL package was renamed back to org.apache.bcel  in:
>
> commit d522432b79044740831a132d8b92e7dab5477444
> Author: Benedikt Ritter 
> Date:   Tue Jun 7 17:28:43 2016 +
>
> The methods to add and delete annotations were changed from public to 
> protected with a confusing comment:
> < public void addAnnotationEntry(AnnotationEntryGen ag)
> ---
> > protected void addAnnotationEntry(final AnnotationEntryGen ag) // TODO 
> > could this be package protected?

The comment makes sense to me.

The method was changed from public to protected, reducing the visibility.
The TODO asks if it could be made package protected, i.e. further reducing the 
visibility.

> I think this might have been a cut and paste error as the same comment was 
> added to other methods, but they were left public (so the comment makes 
> sense).

It seems to me that the other methods were also probably intended to be reduced 
in visibility to protected, but this was not done.

> In any case, the current situation is you can add and delete Attributes but 
> not Annotations.  And, surprise, that is exactly what I need to do.
>
> Any reason not to change these back to public?

Increasing visibility increases the difficulty of testing and increases the 
likelihood of subtle bugs.

> 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

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

strange change to src/main/java/org/apache/bcel/generic/FieldGenOrMethodGen.java

2019-10-17 Thread Mark Roberts

When the BCEL package was renamed back to org.apache.bcel  in:

commit d522432b79044740831a132d8b92e7dab5477444
Author: Benedikt Ritter 
Date:   Tue Jun 7 17:28:43 2016 +

The methods to add and delete annotations were changed from public to protected 
with a confusing comment:
< public void addAnnotationEntry(AnnotationEntryGen ag)
---
> protected void addAnnotationEntry(final AnnotationEntryGen ag) // TODO 
> could this be package protected?

I think this might have been a cut and paste error as the same comment was 
added to other methods, but they were left public (so the comment makes sense).

In any case, the current situation is you can add and delete Attributes but not 
Annotations.  And, surprise, that is exactly what I need to do.

Any reason not to change these back to public?

Thanks,
Mark



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

RE: [bcel] java.util.EmptyStackException at org.apache.bcel.classfile.DescendingVisitor.visitModule (DescendingVisitor.java:592)

2019-09-25 Thread Mark Roberts

Looks like a cut and paste error.  I think the two inner stack.pop() should be 
deleted.  I'm not able to test right now.

Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Wednesday, September 25, 2019 2:55 PM
To: Commons Developers List 
Subject: [bcel] java.util.EmptyStackException at 
org.apache.bcel.classfile.DescendingVisitor.visitModule 
(DescendingVisitor.java:592)

Hi All & Mark Roberts,

It looks like I/we did not test BCEL 6.4.0 well enough or broadly enough.

If I take git master for Apache Commons Pool and update the site report from 
6.3.1 to 6.4.0:

diff --git a/pom.xml b/pom.xml
index c60f6a7..5207358 100644
--- a/pom.xml
+++ b/pom.xml
@@ -213,7 +213,7 @@

 org.apache.bcel
 bcel
-6.3.1
+6.4.0

I get:

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  06:11 min
[INFO] Finished at: 2019-09-25T16:19:15-04:00 [INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on project 
commons-pool2: Execution default-site of goal 
org.apache.maven.plugins:maven-site-plugin:3.7.1:site failed.:
EmptyStackException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.7.1:site (default-site) on project 
commons-pool2: Execution default-site of goal 
org.apache.maven.plugins:maven-site-plugin:3.7.1:site failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution 
default-site of goal org.apache.maven.plugins:maven-site-plugin:3.7.1:site
failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native

RE: [CONFIGURATION] Formatting braces

2019-09-13 Thread Mark Roberts

That's exactly what we do with all our projects here at UW/PLSE.
Mark

-Original Message-
From: James Ring [mailto:s...@jdns.org] 
Sent: Friday, September 13, 2019 6:44 AM
To: Commons Developers List 
Subject: Re: [CONFIGURATION] Formatting braces

What about https://github.com/google/google-java-format ? Just require that it 
be run on check-in, all these style questions go away (as a bonus, it looks 
nice too).

On Wed, Sep 11, 2019 at 6:54 AM Gary Gregory  wrote:
>
> Hi All:
>
> I only hope that this will not turn into a bike shedding thread...
>
> Commons Configuration is one of the few components we have that uses 
> the formatting rule (enforced by Checkstyle) where braces must be on 
> separate lines. In the age of lambdas, this is, IMO, lame (a technical 
> term ;-) for
> example:
>
> public static final ConfigurationConsumer
> DEFAULT_INCLUDE_LISTENER = e ->
> {
> throw e;
> };
>
> public static final ConfigurationConsumer
> NOOP_INCLUDE_LISTENER = e ->
> {
> // noop
> };
>
> Instead of:
>
> public static final ConfigurationConsumer
> DEFAULT_INCLUDE_LISTENER = e -> { throw e; };
>
> public static final ConfigurationConsumer
> NOOP_INCLUDE_LISTENER = e -> { /* noop */ };
>
> I propose a reformatting to use the "{ on the same line" which means 
> that blocks go from:
>
> if (test)
> {
>// this
> }
> else
> {
>   // that
> }
>
> to:
>
> if (test) {
>// this
> } else {
>   // that
> }
>
> and so on.
>
> Gary

-
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] Release 6.4.0

2019-09-09 Thread Mark Roberts

I don’t need to run jacoco to know the coverage is almost zero for the classes 
added to support the new Java 9+ attributes.  I could cobble something up if 
there was some way to add a Java 11 .class file to use as input to a test.

Mark

From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Friday, September 06, 2019 5:01 PM
To: Mark Roberts; Commons Developers List
Subject: Re: [BCEL] Release 6.4.0

Run:

mvn clean site -P jacoco

Then look at the generate site's JaCoCo report and make sure the new code has 
as close to possible to 100% code coverage by the unit tests.

The profile might not be required but it will make sure the right thing 
happens. 

Gary

On Fri, Sep 6, 2019, 19:58 Mark Roberts  wrote:

Sorry - not familiar with the release process.  What does check for code 
coverage mean?

mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Friday, September 6, 2019 3:09 PM
To: Commons Developers List 
Subject: Re: [BCEL] Release 6.4.0

I might have some time over the weekend. Would you mind double checking you 
recent work for code coverage.

Gary

On Fri, Sep 6, 2019, 09:07 Mark Roberts  wrote:

> I'm good.  From our standpoint it would be nice to make a BCEL release 
> so we don't need to include a special version with our tool set.
>
> Thanks,
> Mark
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Sunday, September 1, 2019 3:25 PM
> To: Commons Developers List 
> Subject: [BCEL] Release 6.4.0
>
> Hi All and Mark in particular,
>
> Is there anything more we need for 6.4.0?
>
> Gary
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

RE: [BCEL] Release 6.4.0

2019-09-06 Thread Mark Roberts

I'm good.  From our standpoint it would be nice to make a BCEL release so we 
don't need to include a special version with our tool set.

Thanks,
Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Sunday, September 1, 2019 3:25 PM
To: Commons Developers List 
Subject: [BCEL] Release 6.4.0

Hi All and Mark in particular,

Is there anything more we need for 6.4.0?

Gary

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

RE: [bcel][all] GitHub Actions for Maven builds

2019-08-31 Thread Mark Roberts

As another data point, we (Univ. of Wash. PLSE dept) moved off of Travis to a 
combination of CIrcleCI and Azure Pipleines.

Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Saturday, August 31, 2019 10:22 AM
To: Commons Developers List 
Subject: Re: [bcel][all] GitHub Actions for Maven builds

That is what I thinking, using GitHub actions we can keep builds and sources in 
one place. Well two places: sources+builds in Apache and GitHub.
It feels like we can remove Travis.

Gary

On Sat, Aug 31, 2019, 12:53 Matt Sicker  wrote:

> GitHub Actions are more of a replacement for Travis currently. 
> Provided you’re not doing anything fancy in your pipelines, it might 
> not require Jenkins, either.
>
> On Sat, Aug 31, 2019 at 11:17, Stefan Bodewig  wrote:
>
> > On 2019-08-31, Gary Gregory wrote:
> >
> > > On Sat, Aug 31, 2019 at 10:58 AM Gilles Sadowski 
> > >  >
> > > wrote:
> >
> > >> Links returns "404".
> >
> > > Works for me, anyone else?
> >
> > Only works if you are logged in - an probably a member of the apache 
> > organization. github returns 404 for links you are not allowed to see.
> >
> > Stefan
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> > --
> Matt Sicker 
>


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

RE: [ANNOUNCEMENT] Apache Commons BCEL 6.3.1

2019-05-06 Thread Mark Roberts

I'm very confused by a change made to pom.xml that removed the Javadoc 
additionalparm of -Xdoclint:none but nothing was done to the bcel source files 
to fix all the Javadoc warnings.

Help me understand why this was done.

Thank you,
Mark Roberts

> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Tuesday, March 26, 2019 11:07 AM
> To: annou...@apache.org; Commons Developers List; Commons Users List
> Subject: [ANNOUNCEMENT] Apache Commons BCEL 6.3.1
> 
> The Apache Commons BCEL team is pleased to announce the release of
> Apache Commons BCEL 6.3.1!
> 
> The Byte Code Engineering Library (BCEL) is intended to give users a
> convenient
> way to analyze, create, and manipulate compiled .class files. Classes are
> represented by objects containing all the symbolic information of the 
given
> class: methods, fields and byte code instructions.
> 
> Bug fix release
> 
> FIXED BUGS:
> ===
> 
> o BCEL-267: Race conditions on static fields in BranchHandle and
> InstructionHandle. Thanks to Stephan Herrmann, Sebb, Gary Gregory, Torsten
> Curdt.
> o BCEL-297: Possible NPE in override implementation of Object.equals (#20)
> Thanks to Mark Roberts, mingleizhang.
> o BCEL-315: NullPointerException at
> org.apache.bcel.classfile.FieldOrMethod.dump(). Thanks to Gary Gregory.
> 
> CHANGES:
> 
> 
> o BCEL-298: Add some files to .gitignore (#19) Thanks to mingleizhang.
> 
> Download it from
> https://commons.apache.org/proper/commons-bcel/download_bcel.cgi
> 
> Have fun!
> -Apache Commons BCEL team
> 
> Feedback
> 
> 
> Open source works best when you give feedback:
> 
> http://commons.apache.org/bcel
> 
> Please direct all bug reports to JIRA:
> 
> https://issues.apache.org/jira/browse/BCEL
> 
> Or subscribe to the commons-user mailing list
> 
> Gary Gregory, on behalf of the Apache Commons Team.


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

RE: [BCEL] Console warning

2019-04-10 Thread Mark Roberts

I added that warning while working on the StackMap support for Java7 (and 
beyond).  We were testing (daikon and randoop) on several very large test 
suites and found a large number of class files compiled with an obsolete 
version of Java that generated bogus StackMap entries.  I don't feel too 
strongly that it needs to remain.  Perhaps change the message to suggest 
recompiling with a newer version of Java?  But of course, a lot of these 
classfiles have been passed about and have become disconnected from their 
source.

Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Wednesday, April 10, 2019 4:20 PM
To: Commons Developers List 
Subject: [BCEL] Console warning

Hi All:

In BCEL, we log a warning to the console:

https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/Attribute.java#L240

Which you can't really do anything about since it does not tell you what class 
file it is complaining about.

1) Should remove the logging?
or,
2) Should we improve the logging?
or,
3) Do nothing?

Gary


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

RE: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-05 Thread Mark Roberts

This works, thanks for including the BCEL-295 fix.

So my vote is now +1.

Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Saturday, December 02, 2017 1:04 PM
To: Commons Developers List
Subject: Re: [VOTE] Release Apache Commons BCEL based on RC1

Well, you you try this RC and see if it can replace your custom build?

Gary

On Sat, Dec 2, 2017 at 1:27 PM, Mark Roberts <mar...@cs.washington.edu>
wrote:

> As far as the Daikon tool set is concerned, 295 is not a regression, 
> it is a newly discovered fatal flaw.  We have already had to release a 
> private version of BCEL, we were hoping that the next version would fix that.
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Saturday, December 02, 2017 12:14 PM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL based on RC1
>
> Mark,
>
> Unless BCEL-295 <https://issues.apache.org/jira/browse/BCEL-295> is a 
> regression, I see no technical reason for a -1. What am I missing?
>
> Gary
>
> On Sat, Dec 2, 2017 at 12:35 PM, Mark Roberts 
> <mar...@cs.washington.edu>
> wrote:
>
> > I have to vote -1 until 295 is fixed - this will force us to have a 
> > private version of bcel.
> >
> > https://issues.apache.org/jira/browse/BCEL-295
> >
> > Mark
> >
> >
> > -Original Message-
> > From: Gary Gregory [mailto:ggreg...@apache.org]
> > Sent: Thursday, November 30, 2017 8:18 PM
> > To: Commons Developers List
> > Subject: [VOTE] Release Apache Commons BCEL based on RC1
> >
> > We fixed a few bugs and added some enhancements since we released 
> > Apache Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.
> >
> > Commons BCEL 6.2 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel at svn revision:
> > 23349
> >
> > The tag is here:
> >
> > http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_2_RC
> > 1/
> > (svn revision 1816763)
> > N.B. the SVN revision is required because SVN tags are not immutable.
> >
> > Maven artifacts are here:
> > https://repository.apache.org/content/repositories/
> > orgapachecommons-1294
> >
> > These are the Maven artifacts and their hashes
> >
> > /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar
> > (SHA1: feef9dc39b67bf76d90a16abf3b5711d894bdafc)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.jar.asc
> > (SHA1: 10911db34eabbf5ed77175147d890431815a66e9)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar.asc
> > (SHA1: dd32ec245d2d664ee69a70bde304df5f577c3e8b)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz.asc
> > (SHA1: 1b6562ffec86267c8d1935dc1fa33c0fd225a094)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz.asc
> > (SHA1: b7c31d213469b4044361b780890732f67859ec7e)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip.asc
> > (SHA1: 7137b7dfbc135aed1b2f8c7c974289e5ad645e3b)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar
> > (SHA1: 9de7ca4bbce76f7a877700ffc88bc2e36ef065ea)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar
> > (SHA1: 6eba2e55001a6093c8a9aa72132385e93fbe09d3)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar
> > (SHA1: df05f2afa0f58aefe5c3344fc67295ffc2050d53)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar.asc
> > (SHA1: 4999bb9f6d5ad677f13f1e5e856f8a76fdf3c8fc)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.pom.asc
> > (SHA1: 6fd1c5c4fbc96b83f06c421a99fc3ee7f975c310)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.jar
> > (SHA1: 2c1499b28bf2638cbdb5fa94350d41a46d2bd4e0)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz
> > (SHA1: 9116cfccfb5f55a5a9e46fb685c7aa344712d52e)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip.asc
> > (SHA1: 4b86e83b5c0dcd0e3abe86fda7ff5a9aaa1ab67d)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip
> > (SHA1: 95e191ca708c0187292dbef4fe42fd60f52d1d1a)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar.asc
> > (SHA1: 7e36d6e1ba882adf877306940184732f49c0385b)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar.asc
> > (SHA1: bee5e89f33d3e29d0d2c2d6ab6c56e0c06f0d20c)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz
> > (SHA1: 496c6f58f74ae55f513ed14c7268833289649236)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.pom
> > (SHA1: 3932199e50571760ae8acdd0f153a32891b5696c)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip
> > (SHA1: 42c1b8e8ae6d3dafc56ae9c05c3f3ca0819c782c)
> >
> > I have tested this with Oracle Java 7 using Maven 3.5.2 on Windows 10.
> >
> > Details of changes since 6.1 are in the release

RE: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Mark Roberts

I will give it a try - but might take a couple of days

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Saturday, December 02, 2017 1:04 PM
To: Commons Developers List
Subject: Re: [VOTE] Release Apache Commons BCEL based on RC1

Well, you you try this RC and see if it can replace your custom build?

Gary

On Sat, Dec 2, 2017 at 1:27 PM, Mark Roberts <mar...@cs.washington.edu>
wrote:

> As far as the Daikon tool set is concerned, 295 is not a regression, 
> it is a newly discovered fatal flaw.  We have already had to release a 
> private version of BCEL, we were hoping that the next version would fix that.
>
> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Saturday, December 02, 2017 12:14 PM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL based on RC1
>
> Mark,
>
> Unless BCEL-295 <https://issues.apache.org/jira/browse/BCEL-295> is a 
> regression, I see no technical reason for a -1. What am I missing?
>
> Gary
>
> On Sat, Dec 2, 2017 at 12:35 PM, Mark Roberts 
> <mar...@cs.washington.edu>
> wrote:
>
> > I have to vote -1 until 295 is fixed - this will force us to have a 
> > private version of bcel.
> >
> > https://issues.apache.org/jira/browse/BCEL-295
> >
> > Mark
> >
> >
> > -Original Message-
> > From: Gary Gregory [mailto:ggreg...@apache.org]
> > Sent: Thursday, November 30, 2017 8:18 PM
> > To: Commons Developers List
> > Subject: [VOTE] Release Apache Commons BCEL based on RC1
> >
> > We fixed a few bugs and added some enhancements since we released 
> > Apache Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.
> >
> > Commons BCEL 6.2 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel at svn revision:
> > 23349
> >
> > The tag is here:
> >
> > http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_2_RC
> > 1/
> > (svn revision 1816763)
> > N.B. the SVN revision is required because SVN tags are not immutable.
> >
> > Maven artifacts are here:
> > https://repository.apache.org/content/repositories/
> > orgapachecommons-1294
> >
> > These are the Maven artifacts and their hashes
> >
> > /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar
> > (SHA1: feef9dc39b67bf76d90a16abf3b5711d894bdafc)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.jar.asc
> > (SHA1: 10911db34eabbf5ed77175147d890431815a66e9)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar.asc
> > (SHA1: dd32ec245d2d664ee69a70bde304df5f577c3e8b)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz.asc
> > (SHA1: 1b6562ffec86267c8d1935dc1fa33c0fd225a094)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz.asc
> > (SHA1: b7c31d213469b4044361b780890732f67859ec7e)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip.asc
> > (SHA1: 7137b7dfbc135aed1b2f8c7c974289e5ad645e3b)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar
> > (SHA1: 9de7ca4bbce76f7a877700ffc88bc2e36ef065ea)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar
> > (SHA1: 6eba2e55001a6093c8a9aa72132385e93fbe09d3)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar
> > (SHA1: df05f2afa0f58aefe5c3344fc67295ffc2050d53)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar.asc
> > (SHA1: 4999bb9f6d5ad677f13f1e5e856f8a76fdf3c8fc)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.pom.asc
> > (SHA1: 6fd1c5c4fbc96b83f06c421a99fc3ee7f975c310)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.jar
> > (SHA1: 2c1499b28bf2638cbdb5fa94350d41a46d2bd4e0)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz
> > (SHA1: 9116cfccfb5f55a5a9e46fb685c7aa344712d52e)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip.asc
> > (SHA1: 4b86e83b5c0dcd0e3abe86fda7ff5a9aaa1ab67d)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip
> > (SHA1: 95e191ca708c0187292dbef4fe42fd60f52d1d1a)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar.asc
> > (SHA1: 7e36d6e1ba882adf877306940184732f49c0385b)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar.asc
> > (SHA1: bee5e89f33d3e29d0d2c2d6ab6c56e0c06f0d20c)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz
> > (SHA1: 496c6f58f74ae55f513ed14c7268833289649236)
> > /org/apache/bcel/bcel/6.2/bcel-6.2.pom
> > (SHA1: 3932199e50571760ae8acdd0f153a32891b5696c)
> > /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip
> > (SHA1: 42c1b8e8ae6d3dafc56ae9c05c3f3ca0819c782c)
> >
> > I have tested this with Oracle Java 7 using Maven 3.5.2 on Windows 10.
> >
> > Details of changes since 6.1 are in the release notes:
> >
> &

RE: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Mark Roberts

As far as the Daikon tool set is concerned, 295 is not a regression, it is a 
newly discovered fatal flaw.  We have already had to release a private version 
of BCEL, we were hoping that the next version would fix that.

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Saturday, December 02, 2017 12:14 PM
To: Commons Developers List
Subject: Re: [VOTE] Release Apache Commons BCEL based on RC1

Mark,

Unless BCEL-295 <https://issues.apache.org/jira/browse/BCEL-295> is a 
regression, I see no technical reason for a -1. What am I missing?

Gary

On Sat, Dec 2, 2017 at 12:35 PM, Mark Roberts <mar...@cs.washington.edu>
wrote:

> I have to vote -1 until 295 is fixed - this will force us to have a 
> private version of bcel.
>
> https://issues.apache.org/jira/browse/BCEL-295
>
> Mark
>
>
> -Original Message-
> From: Gary Gregory [mailto:ggreg...@apache.org]
> Sent: Thursday, November 30, 2017 8:18 PM
> To: Commons Developers List
> Subject: [VOTE] Release Apache Commons BCEL based on RC1
>
> We fixed a few bugs and added some enhancements since we released 
> Apache Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.
>
> Commons BCEL 6.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/bcel at svn revision:
> 23349
>
> The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_2_RC1/
> (svn revision 1816763)
> N.B. the SVN revision is required because SVN tags are not immutable.
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/
> orgapachecommons-1294
>
> These are the Maven artifacts and their hashes
>
> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar
> (SHA1: feef9dc39b67bf76d90a16abf3b5711d894bdafc)
> /org/apache/bcel/bcel/6.2/bcel-6.2.jar.asc
> (SHA1: 10911db34eabbf5ed77175147d890431815a66e9)
> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar.asc
> (SHA1: dd32ec245d2d664ee69a70bde304df5f577c3e8b)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz.asc
> (SHA1: 1b6562ffec86267c8d1935dc1fa33c0fd225a094)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz.asc
> (SHA1: b7c31d213469b4044361b780890732f67859ec7e)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip.asc
> (SHA1: 7137b7dfbc135aed1b2f8c7c974289e5ad645e3b)
> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar
> (SHA1: 9de7ca4bbce76f7a877700ffc88bc2e36ef065ea)
> /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar
> (SHA1: 6eba2e55001a6093c8a9aa72132385e93fbe09d3)
> /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar
> (SHA1: df05f2afa0f58aefe5c3344fc67295ffc2050d53)
> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar.asc
> (SHA1: 4999bb9f6d5ad677f13f1e5e856f8a76fdf3c8fc)
> /org/apache/bcel/bcel/6.2/bcel-6.2.pom.asc
> (SHA1: 6fd1c5c4fbc96b83f06c421a99fc3ee7f975c310)
> /org/apache/bcel/bcel/6.2/bcel-6.2.jar
> (SHA1: 2c1499b28bf2638cbdb5fa94350d41a46d2bd4e0)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz
> (SHA1: 9116cfccfb5f55a5a9e46fb685c7aa344712d52e)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip.asc
> (SHA1: 4b86e83b5c0dcd0e3abe86fda7ff5a9aaa1ab67d)
> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip
> (SHA1: 95e191ca708c0187292dbef4fe42fd60f52d1d1a)
> /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar.asc
> (SHA1: 7e36d6e1ba882adf877306940184732f49c0385b)
> /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar.asc
> (SHA1: bee5e89f33d3e29d0d2c2d6ab6c56e0c06f0d20c)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz
> (SHA1: 496c6f58f74ae55f513ed14c7268833289649236)
> /org/apache/bcel/bcel/6.2/bcel-6.2.pom
> (SHA1: 3932199e50571760ae8acdd0f153a32891b5696c)
> /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip
> (SHA1: 42c1b8e8ae6d3dafc56ae9c05c3f3ca0819c782c)
>
> I have tested this with Oracle Java 7 using Maven 3.5.2 on Windows 10.
>
> Details of changes since 6.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
>
>
> Site:
> https://people.apache.org/~ggregory/commons-bcel-3.2-RC1-site.zip
>   (note some *relative* links are broken and the 1.2 directories are
>   not yet created - these will be OK once the site is deployed)
>
> The Clirr and RAT Reports (compared to 6.1) are in the zipped site.
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote. This vote will close no 
> sooner that 72 hours from now, sometime after 05:00 UTC 4-December 
> 2017
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thanks!
>
> Gary Gregory,
> Apache Commons PMC Chair
>
>
> -
> 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: [VOTE] Release Apache Commons BCEL based on RC1

2017-12-02 Thread Mark Roberts

I have to vote -1 until 295 is fixed - this will force us to have a private 
version of bcel.

https://issues.apache.org/jira/browse/BCEL-295

Mark


-Original Message-
From: Gary Gregory [mailto:ggreg...@apache.org] 
Sent: Thursday, November 30, 2017 8:18 PM
To: Commons Developers List
Subject: [VOTE] Release Apache Commons BCEL based on RC1

We fixed a few bugs and added some enhancements since we released Apache 
Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.

Commons BCEL 6.2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/bcel at svn revision:
23349

The tag is here:
http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_2_RC1/
(svn revision 1816763)
N.B. the SVN revision is required because SVN tags are not immutable.

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1294

These are the Maven artifacts and their hashes

/org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar
(SHA1: feef9dc39b67bf76d90a16abf3b5711d894bdafc)
/org/apache/bcel/bcel/6.2/bcel-6.2.jar.asc
(SHA1: 10911db34eabbf5ed77175147d890431815a66e9)
/org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar.asc
(SHA1: dd32ec245d2d664ee69a70bde304df5f577c3e8b)
/org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz.asc
(SHA1: 1b6562ffec86267c8d1935dc1fa33c0fd225a094)
/org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz.asc
(SHA1: b7c31d213469b4044361b780890732f67859ec7e)
/org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip.asc
(SHA1: 7137b7dfbc135aed1b2f8c7c974289e5ad645e3b)
/org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar
(SHA1: 9de7ca4bbce76f7a877700ffc88bc2e36ef065ea)
/org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar
(SHA1: 6eba2e55001a6093c8a9aa72132385e93fbe09d3)
/org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar
(SHA1: df05f2afa0f58aefe5c3344fc67295ffc2050d53)
/org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar.asc
(SHA1: 4999bb9f6d5ad677f13f1e5e856f8a76fdf3c8fc)
/org/apache/bcel/bcel/6.2/bcel-6.2.pom.asc
(SHA1: 6fd1c5c4fbc96b83f06c421a99fc3ee7f975c310)
/org/apache/bcel/bcel/6.2/bcel-6.2.jar
(SHA1: 2c1499b28bf2638cbdb5fa94350d41a46d2bd4e0)
/org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz
(SHA1: 9116cfccfb5f55a5a9e46fb685c7aa344712d52e)
/org/apache/bcel/bcel/6.2/bcel-6.2-src.zip.asc
(SHA1: 4b86e83b5c0dcd0e3abe86fda7ff5a9aaa1ab67d)
/org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip
(SHA1: 95e191ca708c0187292dbef4fe42fd60f52d1d1a)
/org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar.asc
(SHA1: 7e36d6e1ba882adf877306940184732f49c0385b)
/org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar.asc
(SHA1: bee5e89f33d3e29d0d2c2d6ab6c56e0c06f0d20c)
/org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz
(SHA1: 496c6f58f74ae55f513ed14c7268833289649236)
/org/apache/bcel/bcel/6.2/bcel-6.2.pom
(SHA1: 3932199e50571760ae8acdd0f153a32891b5696c)
/org/apache/bcel/bcel/6.2/bcel-6.2-src.zip
(SHA1: 42c1b8e8ae6d3dafc56ae9c05c3f3ca0819c782c)

I have tested this with Oracle Java 7 using Maven 3.5.2 on Windows 10.

Details of changes since 6.1 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt


Site:
https://people.apache.org/~ggregory/commons-bcel-3.2-RC1-site.zip
  (note some *relative* links are broken and the 1.2 directories are
  not yet created - these will be OK once the site is deployed)

The Clirr and RAT Reports (compared to 6.1) are in the zipped site.

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote. This vote will close no sooner 
that 72 hours from now, sometime after 05:00 UTC 4-December 2017

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!

Gary Gregory,
Apache Commons PMC Chair


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

RE: [VOTE][LAZY] Migrate Apache Commons BCEL to git

2017-10-21 Thread Mark Roberts

+1

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Saturday, October 21, 2017 1:22 AM
To: Commons Developers List
Subject: [VOTE][LAZY] Migrate Apache Commons BCEL to git

Hello,

I’d like to move Apache Commons BCEL codebase to git, so I’m calling a vote by 
lazy consensus. If nobody objects within the next 72 hours this vote passes and 
I will start with the migration.

This vote will be open until at least 24-October-2017, 10:30 CEST (UTC+2).

Regards,
Benedikt
-
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: [VOTE] Release Apache Commons BCEL 6.1 based on RC1

2017-09-17 Thread Mark Roberts

Passed all of the UW PLSE Daikon toolset tests.

+1

Mark

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Thursday, September 14, 2017 1:30 PM
To: Commons Developers List
Subject: [VOTE] Release Apache Commons BCEL 6.1 based on RC1

Hi,

we’ve fixed some bugs and added some new feature since Commons BCEL 6.0 was 
released, so I’d like to call a vote to release Commons BCEL 6.1 based on RC1.

BCEL 6.1 RC1 is available for review her:
  https://dist.apache.org/repos/dist/dev/commons/bcel (rev 21612)

The tag is here:
  https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_1_RC1 (rev 
1808392)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1263/org/apache/bcel/bcel/6.1/

These are the Maven artifacts and their hashes

bcel-6.1.jar.asc
(SHA1: a190964c22cb11132f3e14b71adc50b72db8d629)
bcel-6.1-sources.jar.asc
(SHA1: 5c740afacb9267135e39b3746243b22623e81d03)
bcel-6.1-test-sources.jar.asc
(SHA1: e5dcb0adad0f9c812b6da180800948e6e07652b2)
bcel-6.1-tests.jar.asc
(SHA1: 760cb782785426f647771fab73ab58a1cb34a433)
bcel-6.1-javadoc.jar
(SHA1: 64db6246e0b1fc9b4e1ba3c31c7e8251e0fe5acd)
bcel-6.1.pom.asc
(SHA1: ee13e95b11ab53ac1352404423ef365993869c83)
bcel-6.1.pom
(SHA1: b4cff8fd449d6a4ed2252182de949511034ac7b3)
bcel-6.1-sources.jar
(SHA1: fcd80e33305bbc1fdbd9456fb4f5afb454171f09)
bcel-6.1.jar
(SHA1: 6f0534a03433c804c6ad774c9c98fb7637e6fb57)
bcel-6.1-javadoc.jar.asc
(SHA1: 07bbf6ca6519a06a57a5841c768b01ac5a8302a0)
bcel-6.1-test-sources.jar
(SHA1: a73cc36bd1ed46a858316894ec0792de07b5e34a)
bcel-6.1-tests.jar
(SHA1: 71d1a2afe871aa3ece39c4b858445f764c08092d)

I have tested this with JDK 7 using Maven 3.5.0. I’ve also tested with Java 9 
EA b181. The build fails. See BCEL-275.

Details of changes since 6.1 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
http://home.apache.org/~britter/commons/bcel/6.1-RC1/changes-report.html

Site:
http://home.apache.org/~britter/commons/bcel/6.1-RC1
  (note some *relative* links are broken and the 6.1 directories are
  not yet created - these will be OK once the site is deployed)

Clirr Report (compared to 6.1):
http://home.apache.org/~britter/commons/bcel/6.1-RC1/clirr-report.html

Note that Clirr reports several errors.
These are considered OK for the reasons stated below.
These exceptions are also noted in the Changes and Release Notes.

Errors reported:
- methods added to interface: OK because that does not affect binary 
compatibility. The Visitor interface is not meant to be implemented directly by 
clients. This change has also be discussed on the dev ML: 
http://markmail.org/message/n445xf3f5ghkrkwe

RAT Report:
http://home.apache.org/~britter/commons/bcel/6.1-RC1/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now, i.e. sometime after 
22:30 CEST (UTC+2) 17-September 2017

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks!

Benedikt



-
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] Releasing 6.1

2017-08-28 Thread Mark Roberts

Found another issue that needs to be corrected.  I have updated the patch file 
for https://issues.apache.org/jira/browse/BCEL-276.

Thank you
Mark

-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Monday, August 28, 2017 11:36 AM
To: Commons Developers List
Subject: Re: [BCEL] Releasing 6.1

Hello Mark,

> Am 28.08.2017 um 16:39 schrieb Mark Roberts <mar...@cs.washington.edu>:
> 
> As I have noted in previous posts, the UW PLSE Daikon toolset is a major user 
> of BCEL.  I would be happy to help with this release.  Some items/questions 
> to start with:
> 
> - We have submitted three issues and proposed fixes we would really like to 
> see included in this release https://issues.apache.org/jira/browse/BCEL-283 , 
> https://issues.apache.org/jira/browse/BCEL-286  and 
> https://issues.apache.org/jira/browse/BCEL-287 .

Thank you, I will have a look into these.

Benedikt



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

RE: [BCEL] Releasing 6.1

2017-08-28 Thread Mark Roberts

As I have noted in previous posts, the UW PLSE Daikon toolset is a major user 
of BCEL.  I would be happy to help with this release.  Some items/questions to 
start with:

- We have submitted three issues and proposed fixes we would really like to see 
included in this release https://issues.apache.org/jira/browse/BCEL-283 , 
https://issues.apache.org/jira/browse/BCEL-286  and 
https://issues.apache.org/jira/browse/BCEL-287 .

- Is the svn repo still the master?  Will you be creating a branch for the 
release?

Thank you,
Mark Roberts


-Original Message-
From: Benedikt Ritter [mailto:brit...@apache.org] 
Sent: Monday, August 28, 2017 12:14 AM
To: Commons Developers List
Subject: [BCEL] Releasing 6.1

Hi,

I’m hereby announcing, that I’m going to work on BCEL 6.1 release very soon. 
Since I’m not a developer of BCEL, I’m only going to fix code style issues etc. 
So if there is anything missing from a functionality PoV, please go ahead and 
implement it now.

Regards,
Benedikt


-
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

[BCEL6] StackMap vs. StackMapTable

2016-11-09 Thread Mark Roberts

My specification attachments were over the mailer size limit - I have created 
https://issues.apache.org/jira/browse/BCEL-283 with the specs attached.

Mark

> -Original Message-
> From: Mark Roberts [mailto:mar...@cs.washington.edu]
> Sent: Wednesday, November 09, 2016 8:26 AM
> To: 'Commons Developers List'
> Cc: mar...@cs.washington.edu
> Subject: [BCEL6] StackMap vs. StackMapTable
> 
> It turns out we made a mistake with these StackMap renaming changes.  I
> ran into a problem decoding some old .class files and went back to the Java
> Specification Requests (JSRs) to try and understand the history of the
> StackMap attribute.  While I was not able to get the complete story, I have a
> pretty good guess at what happened and it does explain the problem I have
> seen.
> 
> The official introduction of StackMaps appears to be JSR 202 from (approx.)
> Sept. 2006 and it is part of JDK6 (see attached spec) .   However, StackMaps
> were originally proposed much earlier (approx.) March 2002 - see the
> attached verifier spec.  It appears there were some implementations of this
> earlier specification - the ASM tool was one and there may be others.
> 
> The key differences are:
> Typechecker Spec: StackMap attribute with fixed format and no frame
> type byte
> JDK 6 Spec:   StackMapTable attribute with variable format
> including a frame type byte.
> 
> The JVM and the javap tool support BOTH formats.  BCEL recognizes both
> attribute names, but treats them the same, as JDK6 version.
> 
> I don't think the changes will be too difficult.  I will create a new BCEL 
> issue
> with a proposed fix within the next few days.
> 
> Thank you,
> Mark Roberts
> 
> > -Original Message-
> > From: Mark Roberts [mailto:mar...@cs.washington.edu]
> > Sent: Wednesday, June 08, 2016 5:25 AM
> > To: 'Commons Developers List'
> > Subject: RE: [BCEL6] StackMapTable / StackMapTableEntry gone
> >
> > There were duplicate versions of these methods with slightly different
> > names.  We picked the set that seemed to have a better implementation
> > and deleted the other two.  This was done as part of the last two
> > pushes to 6.0 (approx. Feb 2015 and Aug 2015).  A lot of these changes
> > were porting numerous bug fixes and enhancements we (the PLSE group
> at
> > University of
> > Washington) had done to our version of BCEL to provide some basic
> > support for StackMaps so our tools (Daikon, in particular) could fully
> > support Java 7 and Java 8.  See BCEL issues 194 through 213 for some
> general back ground.
> >
> > Thank you,
> > Mark Roberts
> >
> > > -Original Message-
> > > From: James Carman [mailto:ja...@carmanconsulting.com]
> > > Sent: Wednesday, June 08, 2016 4:03 AM
> > > To: Commons Developers List
> > > Subject: Re: [BCEL6] StackMapTable / StackMapTableEntry gone
> > >
> > > Let's be clear here.  We are proposing changing the code because
> > > someone used a SNAPSHOT version and released their code which uses
> it?
> > > That code was never released and I don't know that it's right to
> > > bind us to a work-in-progress.  It's bad enough we have to be
> > > saddled forever with the burden of backward compatibility on code we
> release.
> > >
> > > On the other hand, we've done a very poor job of releasing the
> > > library, so folks did what they had to do to get the new
> > > features/fixes.  So, there definitely are two sides to this situation.
> > >
> > > On Wed, Jun 8, 2016 at 5:17 AM sebb <seb...@gmail.com> wrote:
> > >
> > > > On 8 June 2016 at 10:01, Andrey Loskutov <losku...@gmx.de> wrote:
> > > > > On Wednesday 08 June 2016 08:37 Benedikt Ritter wrote:
> > > > >> Hallo Andrey,
> > > > >>
> > > > >> Andrey Loskutov <losku...@gmx.de> schrieb am Mi., 8. Juni 2016
> > > > >> um
> > > > 09:36 Uhr:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > I'm following the package rename and trying to fix compile
> > > > >> > issues with
> > > > >> > BCEL6 in FindBugs.
> > > > >> >
> > > > >> > Before 6.0 we had both StackMap and StackMapTable classes
> > > > >> > (with StackMapEntry / StackMapTableEntry elements).
> > > > >> > This was added via
> > > > >> > https://issues.apache.org/jira/browse/BCEL-92
> > > > >&

RE: [GitHub] commons-bcel pull request #10: BCEL-276 LocalVariableTypeTable is not update...

2016-09-12 Thread Mark Roberts

This issue needs to be reopened as the changes are incorrect.  I could not
figure out the magic to do so - but I did add comments and attached the
outline of a solution in the form of a diff file.

Thank you,
Mark Roberts

> -Original Message-
> From: asfgit [mailto:g...@git.apache.org]
> Sent: Monday, September 05, 2016 11:46 PM
> To: dev@commons.apache.org
> Subject: [GitHub] commons-bcel pull request #10: BCEL-276
> LocalVariableTypeTable is not update...
> 
> Github user asfgit closed the pull request at:
> 
> https://github.com/apache/commons-bcel/pull/10
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have
your reply
> appear on GitHub as well. If your project does not have this feature
enabled
> and wishes so, or if the feature is enabled but not working, please
contact
> infrastructure at infrastruct...@apache.org or file a JIRA ticket with
INFRA.
> ---
> 
> -
> 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] Need advice on GitHub PR

2016-08-27 Thread Mark Roberts

This sounds very similar to the previous attempt to do this that broke our tool 
Daikon.  Please see https://issues.apache.org/jira/browse/BCEL-79 and make sure 
we're not doing this incorrectly again.  

Unfortunately, I do not have the time right now to do a full review.  If no one 
else volunteers, let me know and I'll see what I can do.

Thanks,
Mark

> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Saturday, August 27, 2016 7:27 AM
> To: Commons Developers List
> Subject: [BCEL] Need advice on GitHub PR
> 
> Hello everybody,
> 
> we have this PR [1] which has been pending for a while. Now we only have one
> comment left [2], which I can't really get my head around (probably due to 
> missing
> experience with byte code generation and stuff :o)
> 
> Does anybody have time to take a look?
> 
> Best regards,
> Benedikt
> 
> [1] https://github.com/apache/commons-bcel/pull/10
> [2] https://github.com/apache/commons-bcel/pull/10#discussion_r75886503


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

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC8

2016-07-11 Thread Mark Roberts

Passed our Daikon testing.
+1

Mark

> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Sunday, July 10, 2016 2:04 PM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC8
> 
> Benedikt Ritter  schrieb am So., 10. Juli 2016 um
> 22:57 Uhr:
> 
> > Hi all,
> >
> > hopefully the final RC for releasing Apache Commons BCEL 6.0 :-)
> > Changes since RC7:
> >
> > - fixed failing build on Windows plattforms
> > - corrected fix for BCEL-262
> >
> > Apache Commons BCEL 6.0 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14344)
> >
> 
> Sorry the revision is incorrect. The correct revision is 14346.
> 
> 
> >
> > The tag is here:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_R
> C8
> >  (rev 1752118)
> >
> > Maven artifacts:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-
> 11
> > 83/org/apache/bcel/bcel/6.0/
> >
> > Maven artifact hashes:
> >
> > bcel-6.0-test-sources.jar
> > (SHA1: 30ba969d603b676929b69228ad0f2a4fc1c9c830)
> > bcel-6.0.pom
> > (SHA1: aff6c560d92df15a207247c5b0293bb734389094)
> > bcel-6.0.jar
> > (SHA1: 7d08bcac4832f81467d3e2ca5bd58ad627288656)
> > bcel-6.0-tests.jar
> > (SHA1: 3536d25398f6f6ac22deb9e446515056191661f7)
> > bcel-6.0-javadoc.jar
> > (SHA1: e47a109aa7416329a9970f0900136cb355af8ac8)
> > bcel-6.0-sources.jar
> > (SHA1: 206dfd32271b9b0150d8211070e5dbbe69cf5154)
> >
> > I've tested with Java 7 & 8 using Maven 3.3.9
> >
> > Details of changes since 5.2 are in the release notes:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel//RELEASE-
> NOTES.txt
> >
> > http://home.apache.org/~britter/commons/bcel/6.0-RC8/changes-
> report.ht
> > ml
> >
> > Site:
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC8
> > (note some *relative* links are broken and the 6.0 directories are not
> > yet created - these will be OK once the site is deployed)
> >
> > Clirr Report (compared to 5.2):
> >
> > http://home.apache.org/~britter/commons/bcel/6.0-RC8/clirr-report.html
> >
> > Note that Clirr reports several errors.
> > These are considered OK for the reasons stated below.
> > These exceptions are also noted in the Changes and Release Notes.
> >
> > Errors reported:
> > - methods added to org.apache.bcel.classfile.Visitor interface: OK
> > because that does not affect binary compatibility.
> > - Removed java.io.Serializable from all classes: OK, because we don't
> > expect anybody to rely on serialization for BCEL classes
> > - Return type of method 'public java.lang.Object getElementAt(int)'
> > has been changed to java.lang.String in class
> org.apache.bcel.verifier.VerifierFactoryListModel:
> > OK, because this class is part of an UI application and for this
> > reason should only used by Swing.
> >
> > RAT Report:
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC8/rat-report.html
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote. This vote will close no
> > sooner that 72 hours from now, i.e. sometime after 23:00 CEST 13-July
> > 2016
> >
> > [ ] +1 Release these artifacts
> > [ ] +0 OK, but...
> > [ ] -0 OK, but really should fix...
> > [ ] -1 I oppose this release because...
> >
> > Thank you!
> > Benedikt
> >
> >


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

RE: How tell which BCEL release?

2016-07-08 Thread Mark Roberts

Great - thanks for all the suggestions.  I will investigate on Monday.

Mark

> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Friday, July 08, 2016 4:18 PM
> To: Commons Developers List
> Subject: Re: How tell which BCEL release?
> 
> Accessible from java.lang.Package
> 
> Gary
> 
> On Fri, Jul 8, 2016 at 4:10 PM, sebb  wrote:
> 
> > The Commons Parent pom includes various items in the jar manifest,
> > including the following:
> >
> > Implementation-Version:
> > Specification-Version:
> >
> > These are both set from project.version.
> >
> >
> >


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

How tell which BCEL release?

2016-07-08 Thread Mark Roberts

Now that BCEL 6.0 looks close, I'm wondering how a client can tell - 
programmatically - which version of BCEL he is running against in order to 
verify it is correct.   Currently, we at PLSE add an extra, dummy class to the 
release in order to do this.   Our goal is to stop shipping our own version and 
use the official 6.0 release - but we still need a way to identify the version. 
 We could do something hokey like looking for a recently added method - but I 
would prefer something more organized. 

Any thoughts?

Mark


> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Thursday, July 07, 2016 11:48 AM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> 
> Thank you Mark, I'll have a look ASAP.
> 
> Mark Roberts <mar...@cs.washington.edu> schrieb am Do., 7. Juli 2016 um
> 18:41:
> 
> > Unit test attached to BCEL-262.
> >
> > Mark
> >
> > > -Original Message-
> > > From: Gary Gregory [mailto:garydgreg...@gmail.com]
> > > Sent: Wednesday, July 06, 2016 2:26 PM
> > > To: Commons Developers List
> > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> > >
> > > I think we should wait for your unit test before we cut another (and
> > final I
> > > hope) RC.
> > >
> > > Gary
> > >
> > > On Wed, Jul 6, 2016 at 10:51 AM, Mark Roberts
> > > <mar...@cs.washington.edu>
> > > wrote:
> > >
> > > > The patch that (was) attached to bcel-262 was correct, it just
> > > > looks like it was never applied.  The line numbers are a little
> > > > off now so I have just updated the patch - the new version is relative 
> > > > to
> RC7.
> > > >
> > > > The example failure shown in the bug report requires running
> > > > Daikon to repro.  I will see if I can produce a reduced test case,
> > > > but it will take a little time.
> > > >
> > > > I just noticed that the package coordinates change (from
> > > > commons/bcel6 back to bcel) was applied to the trunk as well as the RC
> candidates.
> > > > It this change permanent?  I really don't want to edit my sources
> > > > back only to have to change them again at some point in the future.
> > > >
> > > > And here is some good (!) news:  I took the current RC7 sources,
> > > > applied my InvokeInstruction patch, built the system, used
> > > > shade52.xml to get the correct :-) names and inserted the
> > > > resulting bcel.jar into the Daikon system.  It built correctly and
> > > > passed all the regression
> > tests. Ta-
> > > da!
> > > >
> > > > Thank you,
> > > > Mark
> > > >
> > > > > -Original Message-
> > > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > > Sent: Wednesday, July 06, 2016 9:47 AM
> > > > > To: Commons Developers List
> > > > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> > > > >
> > > > > Gary Gregory <garydgreg...@gmail.com> schrieb am Mi., 6. Juli
> > > > > 2016 um
> > > > > 18:37 Uhr:
> > > > >
> > > > > > Can you craft a unit test that makes sure the proper behavior
> > > > > > is in
> > > > place?
> > > > > >
> > > > >
> > > > > That would be awesome. Furthermore you will have to attach the
> > > > > patch to jira or create a GitHub PR, since the ML moes not allow
> > > > > file
> > > attachments.
> > > > >
> > > > > Benedikt
> > > > >
> > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Wed, Jul 6, 2016 at 9:16 AM, Mark Roberts
> > > > > > <mar...@cs.washington.edu>
> > > > > > wrote:
> > > > > >
> > > > > > > Hmm - now I'm thinking the code for InvokeInstruction is not
> > correct.
> > > > > > The
> > > > > > > override method getClassName was added, but my patch was not
> > > > > applied
> > > > > > > to
> > > > > > the
> > > > > > > added code.  I have attached the diff.
> > > > > > >
> > > > > > > Sorry for not catching this the first time.
> > >

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC7

2016-07-07 Thread Mark Roberts

Unit test attached to BCEL-262.

Mark

> -Original Message-
> From: Gary Gregory [mailto:garydgreg...@gmail.com]
> Sent: Wednesday, July 06, 2016 2:26 PM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> 
> I think we should wait for your unit test before we cut another (and final I
> hope) RC.
> 
> Gary
> 
> On Wed, Jul 6, 2016 at 10:51 AM, Mark Roberts
> <mar...@cs.washington.edu>
> wrote:
> 
> > The patch that (was) attached to bcel-262 was correct, it just looks
> > like it was never applied.  The line numbers are a little off now so I
> > have just updated the patch - the new version is relative to RC7.
> >
> > The example failure shown in the bug report requires running Daikon to
> > repro.  I will see if I can produce a reduced test case, but it will
> > take a little time.
> >
> > I just noticed that the package coordinates change (from commons/bcel6
> > back to bcel) was applied to the trunk as well as the RC candidates.
> > It this change permanent?  I really don't want to edit my sources back
> > only to have to change them again at some point in the future.
> >
> > And here is some good (!) news:  I took the current RC7 sources,
> > applied my InvokeInstruction patch, built the system, used shade52.xml
> > to get the correct :-) names and inserted the resulting bcel.jar into
> > the Daikon system.  It built correctly and passed all the regression tests. 
> > Ta-
> da!
> >
> > Thank you,
> > Mark
> >
> > > -Original Message-
> > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > Sent: Wednesday, July 06, 2016 9:47 AM
> > > To: Commons Developers List
> > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> > >
> > > Gary Gregory <garydgreg...@gmail.com> schrieb am Mi., 6. Juli 2016
> > > um
> > > 18:37 Uhr:
> > >
> > > > Can you craft a unit test that makes sure the proper behavior is
> > > > in
> > place?
> > > >
> > >
> > > That would be awesome. Furthermore you will have to attach the patch
> > > to jira or create a GitHub PR, since the ML moes not allow file
> attachments.
> > >
> > > Benedikt
> > >
> > >
> > > > Gary
> > > >
> > > > On Wed, Jul 6, 2016 at 9:16 AM, Mark Roberts
> > > > <mar...@cs.washington.edu>
> > > > wrote:
> > > >
> > > > > Hmm - now I'm thinking the code for InvokeInstruction is not correct.
> > > > The
> > > > > override method getClassName was added, but my patch was not
> > > applied
> > > > > to
> > > > the
> > > > > added code.  I have attached the diff.
> > > > >
> > > > > Sorry for not catching this the first time.
> > > > >
> > > > > Thank you,
> > > > > Mark
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Mark Roberts [mailto:mar...@cs.washington.edu]
> > > > > > Sent: Wednesday, July 06, 2016 6:57 AM
> > > > > > To: 'Commons Developers List'
> > > > > > Subject: RE: [VOTE] Release Apache Commons BCEL 6.0 based on
> > > > > > RC7
> > > > > >
> > > > > > The RELEASE-NOTES.txt entry for BCEL-262 is incorrect.  It
> > > > > > should be
> > > > > exactly
> > > > > > the opposite.  The override was added to InvokeInstruction
> > > > > > because an
> > > > > array
> > > > > > IS a legal operand.  The code is correct, the throw has been
> > removed.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > > > > Sent: Tuesday, July 05, 2016 2:17 AM
> > > > > > > To: Commons Developers List
> > > > > > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on
> > > > > > > RC7
> > > > > > >
> > > > > > > This vote is still pending and nobody has voted so far.
> > > > > > > Please review this RC and cast your votes!
> > > > > > >
> > > > > > > Thank y

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC7

2016-07-06 Thread Mark Roberts

The patch that (was) attached to bcel-262 was correct, it just looks like it 
was never applied.  The line numbers are a little off now so I have just 
updated the patch - the new version is relative to RC7.

The example failure shown in the bug report requires running Daikon to repro.  
I will see if I can produce a reduced test case, but it will take a little time.

I just noticed that the package coordinates change (from commons/bcel6 back to 
bcel) was applied to the trunk as well as the RC candidates.  It this change 
permanent?  I really don't want to edit my sources back only to have to change 
them again at some point in the future.

And here is some good (!) news:  I took the current RC7 sources, applied my 
InvokeInstruction patch, built the system, used shade52.xml to get the correct 
:-) names and inserted the resulting bcel.jar into the Daikon system.  It built 
correctly and passed all the regression tests. Ta-da!

Thank you,
Mark

> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Wednesday, July 06, 2016 9:47 AM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> 
> Gary Gregory <garydgreg...@gmail.com> schrieb am Mi., 6. Juli 2016 um
> 18:37 Uhr:
> 
> > Can you craft a unit test that makes sure the proper behavior is in place?
> >
> 
> That would be awesome. Furthermore you will have to attach the patch to
> jira or create a GitHub PR, since the ML moes not allow file attachments.
> 
> Benedikt
> 
> 
> > Gary
> >
> > On Wed, Jul 6, 2016 at 9:16 AM, Mark Roberts
> > <mar...@cs.washington.edu>
> > wrote:
> >
> > > Hmm - now I'm thinking the code for InvokeInstruction is not correct.
> > The
> > > override method getClassName was added, but my patch was not
> applied
> > > to
> > the
> > > added code.  I have attached the diff.
> > >
> > > Sorry for not catching this the first time.
> > >
> > > Thank you,
> > > Mark
> > >
> > >
> > > > -Original Message-
> > > > From: Mark Roberts [mailto:mar...@cs.washington.edu]
> > > > Sent: Wednesday, July 06, 2016 6:57 AM
> > > > To: 'Commons Developers List'
> > > > Subject: RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> > > >
> > > > The RELEASE-NOTES.txt entry for BCEL-262 is incorrect.  It should
> > > > be
> > > exactly
> > > > the opposite.  The override was added to InvokeInstruction because
> > > > an
> > > array
> > > > IS a legal operand.  The code is correct, the throw has been removed.
> > > >
> > > > Mark
> > > >
> > > > > -Original Message-
> > > > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > > > Sent: Tuesday, July 05, 2016 2:17 AM
> > > > > To: Commons Developers List
> > > > > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> > > > >
> > > > > This vote is still pending and nobody has voted so far. Please
> > > > > review this RC and cast your votes!
> > > > >
> > > > > Thank you!
> > > > > Benedikt
> > > > >
> > > > > Benedikt Ritter <brit...@apache.org> schrieb am Sa., 2. Juli
> > > > > 2016 um
> > > > > 20:52 Uhr:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'd like to release Apache Commons BCEL 6.0 based on RC7.
> > > > > > Changes compared to RC6 are:
> > > > > >
> > > > > > - restored binary compatibility to a greater degree
> > > > > > - fixed issue BCEL-262
> > > > > >
> > > > > > BCEL 6.0 RC7 is available for review here:
> > > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/ (svn
> > > > > > revision
> > > > > > 14251)
> > > > > >
> > > > > > The tag is here:
> > > > > >
> > > > >
> > > >
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_
> > > > RC
> > > > > 7/
> > > > > > (svn revision 1751084)
> > > > > >
> > > > > > Maven artifacts are here:
> > > > > >
> > > >
> https://repository.apache.org/content/repositories/orgapachecommon
> > > > s-
> > > > > 11
> > &

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC7

2016-07-06 Thread Mark Roberts

Hmm - now I'm thinking the code for InvokeInstruction is not correct.  The 
override method getClassName was added, but my patch was not applied to the 
added code.  I have attached the diff.

Sorry for not catching this the first time.

Thank you,
Mark


> -Original Message-
> From: Mark Roberts [mailto:mar...@cs.washington.edu]
> Sent: Wednesday, July 06, 2016 6:57 AM
> To: 'Commons Developers List'
> Subject: RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> 
> The RELEASE-NOTES.txt entry for BCEL-262 is incorrect.  It should be exactly
> the opposite.  The override was added to InvokeInstruction because an array
> IS a legal operand.  The code is correct, the throw has been removed.
> 
> Mark
> 
> > -Original Message-
> > From: Benedikt Ritter [mailto:brit...@apache.org]
> > Sent: Tuesday, July 05, 2016 2:17 AM
> > To: Commons Developers List
> > Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> >
> > This vote is still pending and nobody has voted so far. Please review
> > this RC and cast your votes!
> >
> > Thank you!
> > Benedikt
> >
> > Benedikt Ritter <brit...@apache.org> schrieb am Sa., 2. Juli 2016 um
> > 20:52 Uhr:
> >
> > > Hi,
> > >
> > > I'd like to release Apache Commons BCEL 6.0 based on RC7. Changes
> > > compared to RC6 are:
> > >
> > > - restored binary compatibility to a greater degree
> > > - fixed issue BCEL-262
> > >
> > > BCEL 6.0 RC7 is available for review here:
> > > https://dist.apache.org/repos/dist/dev/commons/bcel/ (svn revision
> > > 14251)
> > >
> > > The tag is here:
> > >
> >
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC
> > 7/
> > > (svn revision 1751084)
> > >
> > > Maven artifacts are here:
> > >
> https://repository.apache.org/content/repositories/orgapachecommons-
> > 11
> > > 81/org/apache/bcel/bcel/6.0/
> > >
> > > These are the Maven artifacts and their hashes
> > >
> > > bcel-6.0-javadoc.jar
> > >   (SHA1: f1e1534867a901b9ba4884e5805317635c324589)
> > > bcel-6.0-sources.jar
> > >   (SHA1: 9ba3b50aa95289d01ec119b60be68eb4c608ba1d)
> > > bcel-6.0-test-sources.jar
> > >   (SHA1: 484b29d3a73fbe0c103d85965c4fd22e6253f545)
> > > bcel-6.0-tests.jar
> > >   (SHA1: f8b5857f3245e10548ef29cf7006c045b913a199)
> > > bcel-6.0.jar
> > >   (SHA1: fe1ecaf2ba3b1f9f18cdde4f13943e3ccc1d5e69)
> > > bcel-6.0.pom
> > >   (SHA1: ea17ee1b2c28804437212970ea2d273efeb3807e)
> > >
> > > I have tested this with JDK 7, 8 using Maven 3.3.9.
> > >
> > > Details of changes since 1.1 are in the release notes:
> > >   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-
> > NOTES.txt
> > >
> > > http://home.apache.org/~britter/commons/bcel/6.0-RC7/changes-
> > report.ht
> > > ml
> > >
> > > Site:
> > >   http://home.apache.org/~britter/commons/bcel/6.0-RC7/
> > > (note some *relative* links are broken and the 6.0 directories are
> > > not yet created - these will be OK once the site is deployed)
> > >
> > > Clirr Report (compared to 5.2):
> > >
> > > http://home.apache.org/~britter/commons/bcel/6.0-RC7/clirr-report.ht
> > > ml
> > >
> > > Note that Clirr reports several errors.
> > > These are considered OK for the reasons stated below.
> > > These exceptions are also noted in the Changes and Release Notes.
> > >
> > > Errors reported:
> > > - methods added to org.apache.bcel.classfile.Visitor interface: OK
> > > because that does not affect binary compatibility.
> > > - Removed java.io.Serializable from all classes: OK, because we
> > > don't expect anybody to rely on serialization for BCEL classes
> > > - Return type of method 'public java.lang.Object getElementAt(int)'
> > > has been changed to java.lang.String in class
> > > org.apache.bcel.verifier.VerifierFactoryListModel: OK, because this
> > > class is part of an UI application and for this reason should only
> > > used by
> > Swing.
> > >
> > > RAT Report:
> > >
> > > http://home.apache.org/~britter/commons/bcel/6.0-RC7/rat-
> report.html
> > >
> > > KEYS:
> > >   https://www.apache.org/dist/commons/KEYS
> > >
> > > Please review the release candidate and vote. This vote will close
> > > no sooner that 72 hours from now, i.e. sometime after 21:00 CEST
> > > 05-July
> > > 2016
> > >
> > > [ ] +1 Release these artifacts
> > > [ ] +0 OK, but...
> > > [ ] -0 OK, but really should fix...
> > > [ ] -1 I oppose this release because...
> > >
> > > Thanks!
> > > Benedikt
> > >


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

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC7

2016-07-06 Thread Mark Roberts

The RELEASE-NOTES.txt entry for BCEL-262 is incorrect.  It should be exactly 
the opposite.  The override was added to InvokeInstruction because an array IS 
a legal operand.  The code is correct, the throw has been removed.

Mark

> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Tuesday, July 05, 2016 2:17 AM
> To: Commons Developers List
> Subject: Re: [VOTE] Release Apache Commons BCEL 6.0 based on RC7
> 
> This vote is still pending and nobody has voted so far. Please review this RC
> and cast your votes!
> 
> Thank you!
> Benedikt
> 
> Benedikt Ritter  schrieb am Sa., 2. Juli 2016 um
> 20:52 Uhr:
> 
> > Hi,
> >
> > I'd like to release Apache Commons BCEL 6.0 based on RC7. Changes
> > compared to RC6 are:
> >
> > - restored binary compatibility to a greater degree
> > - fixed issue BCEL-262
> >
> > BCEL 6.0 RC7 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/bcel/ (svn revision
> > 14251)
> >
> > The tag is here:
> >
> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_RC
> 7/
> > (svn revision 1751084)
> >
> > Maven artifacts are here:
> > https://repository.apache.org/content/repositories/orgapachecommons-
> 11
> > 81/org/apache/bcel/bcel/6.0/
> >
> > These are the Maven artifacts and their hashes
> >
> > bcel-6.0-javadoc.jar
> >   (SHA1: f1e1534867a901b9ba4884e5805317635c324589)
> > bcel-6.0-sources.jar
> >   (SHA1: 9ba3b50aa95289d01ec119b60be68eb4c608ba1d)
> > bcel-6.0-test-sources.jar
> >   (SHA1: 484b29d3a73fbe0c103d85965c4fd22e6253f545)
> > bcel-6.0-tests.jar
> >   (SHA1: f8b5857f3245e10548ef29cf7006c045b913a199)
> > bcel-6.0.jar
> >   (SHA1: fe1ecaf2ba3b1f9f18cdde4f13943e3ccc1d5e69)
> > bcel-6.0.pom
> >   (SHA1: ea17ee1b2c28804437212970ea2d273efeb3807e)
> >
> > I have tested this with JDK 7, 8 using Maven 3.3.9.
> >
> > Details of changes since 1.1 are in the release notes:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-
> NOTES.txt
> >
> > http://home.apache.org/~britter/commons/bcel/6.0-RC7/changes-
> report.ht
> > ml
> >
> > Site:
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC7/
> > (note some *relative* links are broken and the 6.0 directories are not
> > yet created - these will be OK once the site is deployed)
> >
> > Clirr Report (compared to 5.2):
> >
> > http://home.apache.org/~britter/commons/bcel/6.0-RC7/clirr-report.html
> >
> > Note that Clirr reports several errors.
> > These are considered OK for the reasons stated below.
> > These exceptions are also noted in the Changes and Release Notes.
> >
> > Errors reported:
> > - methods added to org.apache.bcel.classfile.Visitor interface: OK
> > because that does not affect binary compatibility.
> > - Removed java.io.Serializable from all classes: OK, because we don't
> > expect anybody to rely on serialization for BCEL classes
> > - Return type of method 'public java.lang.Object getElementAt(int)'
> > has been changed to java.lang.String in class
> > org.apache.bcel.verifier.VerifierFactoryListModel: OK, because this
> > class is part of an UI application and for this reason should only used by
> Swing.
> >
> > RAT Report:
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC7/rat-report.html
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote. This vote will close no
> > sooner that 72 hours from now, i.e. sometime after 21:00 CEST 05-July
> > 2016
> >
> > [ ] +1 Release these artifacts
> > [ ] +0 OK, but...
> > [ ] -0 OK, but really should fix...
> > [ ] -1 I oppose this release because...
> >
> > Thanks!
> > Benedikt
> >


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

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC6

2016-06-22 Thread Mark Roberts

First, I must apologize for being a little sloppy in my analysis of the RC. 

 As previously noted https://issues.apache.org/jira/browse/BCEL-262 is open and 
is a problem for Daikon.  However, I just noticed my changes - as applied by 
r1702349 | sebb | 2015-09-10 16:30:33 -0700 (Thu, 10 Sep 2015) are incomplete.  
I have attached a diff file to the issue with the correction to allow arrays as 
arguments.

I also missed that https://issues.apache.org/jira/browse/BCEL-243 is still 
open.  This is also a blocker for Daikon.  There is a test case I submitted 
that looks like it was added, but perhaps not as it should show up as a failure 
on mvn test.  I do not believe that correction attached to the issue has been 
accepted.

Hopefully, I have not missed anything else.

Thank you,
Mark
 
> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Monday, June 20, 2016 12:37 PM
> To: Commons Developers List
> Cc: findbugs-disc...@cs.umd.edu; findbugs-c...@lists.sourceforge.net
> Subject: [VOTE] Release Apache Commons BCEL 6.0 based on RC6
> 
> Hi,
> 
> after some build related problems with RC5, I'd like to call a vote to release
> Apache Commons BCEL 6.0 based on RC6. The only changes compared to
> RC5 is a fix in the source assembly: It now includes all files necessary to 
> run a
> clean build.
> 
> BCEL 6.0 RC6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14065)
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_R
> C6
>  (rev 1749388)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-
> 1179/org/apache/bcel/bcel/6.0/
> 
> These are the Maven artifacts and their hashes:
> 
> bcel-6.0-javadoc.jar
> (SHA1: 89cf95656f0f8a93e77100c8d5811f7cd9af866b)
> bcel-6.0-sources.jar
> (SHA1: 162f96530e8935e8a71a9e6d5497026aa3bdc945)
> bcel-6.0-test-sources.jar
> (SHA1: 2b07be3a0a4560c9766d3261cd012cf636fe965a)
> bcel-6.0-tests.jar
> (SHA1: 9e825da46e0cd66f87ccd907a43c4e2ebd15b8d6)
> bcel-6.0.jar
> (SHA1: 09d0a4c32ba6c3c22f0680f89ceeaf3e677ac659)
> bcel-6.0.pom
> (SHA1: a5d48ac34909f3a0ac788d37835075be5c2bb9d7)
> 
> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
> 
> Details of changes since 5.2 are in the release notes:
>   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/changes-
> report.html
> 
> Site:
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/
> (note some *relative* links are broken and the 6.0 directories are not yet
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 5.2):
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/clirr-report.html
> 
> Note that Clirr reports several errors. These have been discussed on the ML
> already and I uploaded the site a while ago giving everybody the opportunity
> to raise objections against these changes. These changes are also explicitly
> noted in the Release notes.
> 
> Furthermore java.io.Serializable has been dropped from all BCEL classes. An
> extended Clirr report including this change can be reviewed here:
> 
> http://home.apache.org/~britter/commons/bcel/6.0-RC6/bcel5-bcel6-clirr-
> report.html
> 
> We don't consider this to be a problem because we don't see a reason for
> users to serialize BCEL classes.
> 
> RAT Report:
> http://home.apache.org/~britter/commons/bcel/6.0-RC6/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. sometime after
> 22:00 CEST 23-June 2016
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
> 
> We're almost there... :-)
> Thanks!
> Benedikt


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

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC6

2016-06-21 Thread Mark Roberts

Thanks to sebb's suggestion of using shade I was able to test RC6.

Unfortunately, I am unable to vote as rev 1747124 breaks Daikon.  (We are 
required to build with -Werror).  This change is not in the active tree so 
that's good.  The problem is that  
https://issues.apache.org/jira/browse/BCEL-262 is unresolved.  There is a 
suggested workaround for the deprecation, but it is very awkward:
invoke.getClassName(pool) versus 
invoke.getReferenceType(pool).getClass().getName()

Thanks,
Mark


> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Monday, June 20, 2016 12:37 PM
> To: Commons Developers List
> Cc: findbugs-disc...@cs.umd.edu; findbugs-c...@lists.sourceforge.net
> Subject: [VOTE] Release Apache Commons BCEL 6.0 based on RC6
> 
> Hi,
> 
> after some build related problems with RC5, I'd like to call a vote to release
> Apache Commons BCEL 6.0 based on RC6. The only changes compared to
> RC5 is a fix in the source assembly: It now includes all files necessary to 
> run a
> clean build.
> 
> BCEL 6.0 RC6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14065)
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_R
> C6
>  (rev 1749388)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-
> 1179/org/apache/bcel/bcel/6.0/
> 
> These are the Maven artifacts and their hashes:
> 
> bcel-6.0-javadoc.jar
> (SHA1: 89cf95656f0f8a93e77100c8d5811f7cd9af866b)
> bcel-6.0-sources.jar
> (SHA1: 162f96530e8935e8a71a9e6d5497026aa3bdc945)
> bcel-6.0-test-sources.jar
> (SHA1: 2b07be3a0a4560c9766d3261cd012cf636fe965a)
> bcel-6.0-tests.jar
> (SHA1: 9e825da46e0cd66f87ccd907a43c4e2ebd15b8d6)
> bcel-6.0.jar
> (SHA1: 09d0a4c32ba6c3c22f0680f89ceeaf3e677ac659)
> bcel-6.0.pom
> (SHA1: a5d48ac34909f3a0ac788d37835075be5c2bb9d7)
> 
> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
> 
> Details of changes since 5.2 are in the release notes:
>   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/changes-
> report.html
> 
> Site:
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/
> (note some *relative* links are broken and the 6.0 directories are not yet
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 5.2):
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/clirr-report.html
> 
> Note that Clirr reports several errors. These have been discussed on the ML
> already and I uploaded the site a while ago giving everybody the opportunity
> to raise objections against these changes. These changes are also explicitly
> noted in the Release notes.
> 
> Furthermore java.io.Serializable has been dropped from all BCEL classes. An
> extended Clirr report including this change can be reviewed here:
> 
> http://home.apache.org/~britter/commons/bcel/6.0-RC6/bcel5-bcel6-clirr-
> report.html
> 
> We don't consider this to be a problem because we don't see a reason for
> users to serialize BCEL classes.
> 
> RAT Report:
> http://home.apache.org/~britter/commons/bcel/6.0-RC6/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. sometime after
> 22:00 CEST 23-June 2016
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
> 
> We're almost there... :-)
> Thanks!
> Benedikt


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

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC6

2016-06-20 Thread Mark Roberts

Sorry - I'm replying to my own post.  Is there any chance that there is a 
revision point in the active tree that corresponds exactly to RC6 but without 
the path changes?  I could do some testing on that.

Probably too much to hope for.

Thanks,
Mark

> -Original Message-
> From: Mark Roberts [mailto:mar...@cs.washington.edu]
> Sent: Monday, June 20, 2016 4:12 PM
> To: 'Commons Developers List'
> Cc: 'findbugs-disc...@cs.umd.edu'; 'findbugs-c...@lists.sourceforge.net'
> Subject: RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC6
> 
> Well I was clearly confused about this release.  It has reverted back to the 
> old
> class hierarchy in the name of binary compatibility.  I can see now that that
> was the intention and it makes sense.  However, I cannot test it (and hence
> vote up or down) as I am certainly not going to edit all my sources back to 
> the
> 'old' system.
> 
> So my question is what is the plan?  This release gets me no closer to a place
> where I can quit providing my own version of BCEL with our Daikon product.
> What is the plan for a release from the active tree with the new class
> hierarchy?
> 
> Thank you,
> Mark Roberts
> 
> 
> > -Original Message-
> > From: Benedikt Ritter [mailto:brit...@apache.org]
> > Sent: Monday, June 20, 2016 12:37 PM
> > To: Commons Developers List
> > Cc: findbugs-disc...@cs.umd.edu; findbugs-c...@lists.sourceforge.net
> > Subject: [VOTE] Release Apache Commons BCEL 6.0 based on RC6
> >
> > Hi,
> >
> > after some build related problems with RC5, I'd like to call a vote to
> > release Apache Commons BCEL 6.0 based on RC6. The only changes
> > compared to
> > RC5 is a fix in the source assembly: It now includes all files
> > necessary to run a clean build.
> >
> > BCEL 6.0 RC6 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14065)
> >
> > The tag is here:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_R
> > C6
> >  (rev 1749388)
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-
> > 1179/org/apache/bcel/bcel/6.0/
> >
> > These are the Maven artifacts and their hashes:
> >
> > bcel-6.0-javadoc.jar
> > (SHA1: 89cf95656f0f8a93e77100c8d5811f7cd9af866b)
> > bcel-6.0-sources.jar
> > (SHA1: 162f96530e8935e8a71a9e6d5497026aa3bdc945)
> > bcel-6.0-test-sources.jar
> > (SHA1: 2b07be3a0a4560c9766d3261cd012cf636fe965a)
> > bcel-6.0-tests.jar
> > (SHA1: 9e825da46e0cd66f87ccd907a43c4e2ebd15b8d6)
> > bcel-6.0.jar
> > (SHA1: 09d0a4c32ba6c3c22f0680f89ceeaf3e677ac659)
> > bcel-6.0.pom
> > (SHA1: a5d48ac34909f3a0ac788d37835075be5c2bb9d7)
> >
> > I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
> >
> > Details of changes since 5.2 are in the release notes:
> >   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-
> NOTES.txt
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC6/changes-
> > report.html
> >
> > Site:
> >   http://home.apache.org/~britter/commons/bcel/6.0-RC6/
> > (note some *relative* links are broken and the 6.0 directories are not
> > yet created - these will be OK once the site is deployed)
> >
> > Clirr Report (compared to 5.2):
> >
> > http://home.apache.org/~britter/commons/bcel/6.0-RC6/clirr-report.html
> >
> > Note that Clirr reports several errors. These have been discussed on
> > the ML already and I uploaded the site a while ago giving everybody
> > the opportunity to raise objections against these changes. These
> > changes are also explicitly noted in the Release notes.
> >
> > Furthermore java.io.Serializable has been dropped from all BCEL
> > classes. An extended Clirr report including this change can be reviewed
> here:
> >
> > http://home.apache.org/~britter/commons/bcel/6.0-RC6/bcel5-bcel6-clirr
> > -
> > report.html
> >
> > We don't consider this to be a problem because we don't see a reason
> > for users to serialize BCEL classes.
> >
> > RAT Report:
> >
> > http://home.apache.org/~britter/commons/bcel/6.0-RC6/rat-report.html
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner that 72 hours from now, i.e. sometime
> > after
> > 22:00 CEST 23-June 2016
> >
> > [ ] +1 Release these artifacts
> > [ ] +0 OK, but...
> > [ ] -0 OK, but really should fix...
> > [ ] -1 I oppose this release because...
> >
> > We're almost there... :-)
> > Thanks!
> > Benedikt


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

RE: [VOTE] Release Apache Commons BCEL 6.0 based on RC6

2016-06-20 Thread Mark Roberts

Well I was clearly confused about this release.  It has reverted back to the 
old class hierarchy in the name of binary compatibility.  I can see now that 
that was the intention and it makes sense.  However, I cannot test it (and 
hence vote up or down) as I am certainly not going to edit all my sources back 
to the 'old' system. 

So my question is what is the plan?  This release gets me no closer to a place 
where I can quit providing my own version of BCEL with our Daikon product.  
What is the plan for a release from the active tree with the new class 
hierarchy?

Thank you,
Mark Roberts


> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Monday, June 20, 2016 12:37 PM
> To: Commons Developers List
> Cc: findbugs-disc...@cs.umd.edu; findbugs-c...@lists.sourceforge.net
> Subject: [VOTE] Release Apache Commons BCEL 6.0 based on RC6
> 
> Hi,
> 
> after some build related problems with RC5, I'd like to call a vote to release
> Apache Commons BCEL 6.0 based on RC6. The only changes compared to
> RC5 is a fix in the source assembly: It now includes all files necessary to 
> run a
> clean build.
> 
> BCEL 6.0 RC6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/bcel (rev 14065)
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/bcel/tags/BCEL_6_0_R
> C6
>  (rev 1749388)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-
> 1179/org/apache/bcel/bcel/6.0/
> 
> These are the Maven artifacts and their hashes:
> 
> bcel-6.0-javadoc.jar
> (SHA1: 89cf95656f0f8a93e77100c8d5811f7cd9af866b)
> bcel-6.0-sources.jar
> (SHA1: 162f96530e8935e8a71a9e6d5497026aa3bdc945)
> bcel-6.0-test-sources.jar
> (SHA1: 2b07be3a0a4560c9766d3261cd012cf636fe965a)
> bcel-6.0-tests.jar
> (SHA1: 9e825da46e0cd66f87ccd907a43c4e2ebd15b8d6)
> bcel-6.0.jar
> (SHA1: 09d0a4c32ba6c3c22f0680f89ceeaf3e677ac659)
> bcel-6.0.pom
> (SHA1: a5d48ac34909f3a0ac788d37835075be5c2bb9d7)
> 
> I have tested this with Java 7 and 8 using Maven 3.3.9 on Mac OS 10.11.5.
> 
> Details of changes since 5.2 are in the release notes:
>   https://dist.apache.org/repos/dist/dev/commons/bcel/RELEASE-NOTES.txt
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/changes-
> report.html
> 
> Site:
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/
> (note some *relative* links are broken and the 6.0 directories are not yet
> created - these will be OK once the site is deployed)
> 
> Clirr Report (compared to 5.2):
>   http://home.apache.org/~britter/commons/bcel/6.0-RC6/clirr-report.html
> 
> Note that Clirr reports several errors. These have been discussed on the ML
> already and I uploaded the site a while ago giving everybody the opportunity
> to raise objections against these changes. These changes are also explicitly
> noted in the Release notes.
> 
> Furthermore java.io.Serializable has been dropped from all BCEL classes. An
> extended Clirr report including this change can be reviewed here:
> 
> http://home.apache.org/~britter/commons/bcel/6.0-RC6/bcel5-bcel6-clirr-
> report.html
> 
> We don't consider this to be a problem because we don't see a reason for
> users to serialize BCEL classes.
> 
> RAT Report:
> http://home.apache.org/~britter/commons/bcel/6.0-RC6/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now, i.e. sometime after
> 22:00 CEST 23-June 2016
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
> 
> We're almost there... :-)
> Thanks!
> Benedikt


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

RE: [BCEL] Release Candidate on Thursday

2016-06-17 Thread Mark Roberts

I think sebb already took care of these two issues.

> -Original Message-
> From: Benedikt Ritter [mailto:benerit...@gmail.com]
> Sent: Friday, June 17, 2016 9:50 AM
> To: Commons Developers List
> Subject: Re: [BCEL] Release Candidate on Thursday
> 
> Hello Mark,
> 
> Mark Roberts <mar...@cs.washington.edu> schrieb am Di., 14. Juni 2016 um
> 18:31 Uhr:
> 
> > People, please look at the data base before you post.   There has been a
> > fix available since August of last year.   (Shortly before the last effort
> > to produce a 6.0 pooped out.)  There is also a test case that
> > demonstrates the problem.
> >
> 
> Thank you for pointing this out. I understand your frustration since your 
> work seems
> to be blocked because of BCEL.
> However your mail came along a bit aggressively. I've just jumped into the
> development of BCEL because I want to help. This is the reason I may not have
> complete overview over the project. Part of our release process is to go 
> through all
> the issues targeting upcoming release and apply available fixes. I will have 
> a look at
> BCEL-243 and BCEL-195.
> 
> I did not manage to create RC1 yesterday. I hope to have more time this 
> weekend.
> 
> Best regards, and again thank you for your help and your patience.
> Benedikt
> 
> 
> >
> > > -Original Message-
> > > From: Andrey Loskutov [mailto:losku...@gmx.de]
> > > Sent: Tuesday, June 14, 2016 9:27 AM
> > > To: Commons Developers List; Mark Roberts; 'Commons Developers List'
> > > Subject: RE: [BCEL] Release Candidate on Thursday
> > >
> > > 1) You mentioned "private Daikon" build. Can you propose a patch?
> > > 2) The bcel-243 reads as an enhancement (some functionality from 1.8
> > > is missing). Is this true? Are there any regressions or any errors
> > > which
> > can be
> > > demonstrated with current trunk state? It would be nice to add this
> > > info
> > to
> > > Jira task.
> > >
> > >
> > > Am 14. Juni 2016 18:04:24 MESZ, schrieb Mark Roberts
> > > <mar...@cs.washington.edu>:
> > > >243 is a show stopper for Daikon.  It will continue to be shipped
> > > >with our private version of BCEL if it is not fixed.
> > > >
> > > >> -Original Message-
> > > >> From: James Carman [mailto:ja...@carmanconsulting.com]
> > > >> Sent: Tuesday, June 14, 2016 8:51 AM
> > > >> To: Commons Developers List
> > > >> Subject: Re: [BCEL] Release Candidate on Thursday
> > > >>
> > > >> Are they show stoppers?
> > > >>
> > > >> On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
> > > >> <mar...@cs.washington.edu>
> > > >> wrote:
> > > >>
> > > >> > I can tell you right now I would vote -1 as you have not picked
> > > >> > up
> > > >the
> > > >> > fix for https://issues.apache.org/jira/browse/BCEL-243.
> > > >> >
> > > >> > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is
> > > >fixed,
> > > >> > but has not been closed.
> > > >> >
> > > >> >
> > > >> > Thank you,
> > > >> > Mark Roberts
> > > >> >
> > > >> > > -Original Message-
> > > >> > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > >> > > Sent: Monday, June 13, 2016 11:49 PM
> > > >> > > To: Commons Developers List
> > > >> > > Subject: [BCEL] Release Candidate on Thursday
> > > >> > >
> > > >> > > Hi,
> > > >> > >
> > > >> > > I'm going to try to create an RC for BCEL 6.0 on friday.
> > > >> > > Please
> > > >have
> > > >> > > a
> > > >> > look at
> > > >> > > the current state of the code base and report any issues you see.
> > > >> > >
> > > >> > > Thank you!
> > > >> > > Benedikt
> > > >> >
> > > >> >
> > > >> >
> > > >---
> > > >--
> > > >> > 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
> > >
> > > --
> > > Kind regards,
> > > Andrey Loskutov
> > >
> > > http://google.com/+AndreyLoskutov
> >
> >
> > -
> > 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] Release Candidate on Thursday

2016-06-14 Thread Mark Roberts

People, please look at the data base before you post.   There has been a fix 
available since August of last year.   (Shortly before the last effort to 
produce a 6.0 pooped out.)  There is also a test case that demonstrates the 
problem.

> -Original Message-
> From: Andrey Loskutov [mailto:losku...@gmx.de]
> Sent: Tuesday, June 14, 2016 9:27 AM
> To: Commons Developers List; Mark Roberts; 'Commons Developers List'
> Subject: RE: [BCEL] Release Candidate on Thursday
> 
> 1) You mentioned "private Daikon" build. Can you propose a patch?
> 2) The bcel-243 reads as an enhancement (some functionality from 1.8 is
> missing). Is this true? Are there any regressions or any errors which can be
> demonstrated with current trunk state? It would be nice to add this info to
> Jira task.
> 
> 
> Am 14. Juni 2016 18:04:24 MESZ, schrieb Mark Roberts
> <mar...@cs.washington.edu>:
> >243 is a show stopper for Daikon.  It will continue to be shipped with
> >our private version of BCEL if it is not fixed.
> >
> >> -Original Message-
> >> From: James Carman [mailto:ja...@carmanconsulting.com]
> >> Sent: Tuesday, June 14, 2016 8:51 AM
> >> To: Commons Developers List
> >> Subject: Re: [BCEL] Release Candidate on Thursday
> >>
> >> Are they show stoppers?
> >>
> >> On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
> >> <mar...@cs.washington.edu>
> >> wrote:
> >>
> >> > I can tell you right now I would vote -1 as you have not picked up
> >the
> >> > fix for https://issues.apache.org/jira/browse/BCEL-243.
> >> >
> >> > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is
> >fixed,
> >> > but has not been closed.
> >> >
> >> >
> >> > Thank you,
> >> > Mark Roberts
> >> >
> >> > > -Original Message-
> >> > > From: Benedikt Ritter [mailto:brit...@apache.org]
> >> > > Sent: Monday, June 13, 2016 11:49 PM
> >> > > To: Commons Developers List
> >> > > Subject: [BCEL] Release Candidate on Thursday
> >> > >
> >> > > Hi,
> >> > >
> >> > > I'm going to try to create an RC for BCEL 6.0 on friday. Please
> >have
> >> > > a
> >> > look at
> >> > > the current state of the code base and report any issues you see.
> >> > >
> >> > > Thank you!
> >> > > Benedikt
> >> >
> >> >
> >> >
> >-
> >> > 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
> 
> --
> Kind regards,
> Andrey Loskutov
> 
> http://google.com/+AndreyLoskutov


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

RE: [BCEL] Release Candidate on Thursday

2016-06-14 Thread Mark Roberts

243 is a show stopper for Daikon.  It will continue to be shipped with our 
private version of BCEL if it is not fixed.

> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Tuesday, June 14, 2016 8:51 AM
> To: Commons Developers List
> Subject: Re: [BCEL] Release Candidate on Thursday
> 
> Are they show stoppers?
> 
> On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts
> <mar...@cs.washington.edu>
> wrote:
> 
> > I can tell you right now I would vote -1 as you have not picked up the
> > fix for https://issues.apache.org/jira/browse/BCEL-243.
> >
> > Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed,
> > but has not been closed.
> >
> >
> > Thank you,
> > Mark Roberts
> >
> > > -Original Message-
> > > From: Benedikt Ritter [mailto:brit...@apache.org]
> > > Sent: Monday, June 13, 2016 11:49 PM
> > > To: Commons Developers List
> > > Subject: [BCEL] Release Candidate on Thursday
> > >
> > > Hi,
> > >
> > > I'm going to try to create an RC for BCEL 6.0 on friday. Please have
> > > a
> > look at
> > > the current state of the code base and report any issues you see.
> > >
> > > Thank you!
> > > Benedikt
> >
> >
> > -
> > 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] Release Candidate on Thursday

2016-06-14 Thread Mark Roberts

I can tell you right now I would vote -1 as you have not picked up the fix for 
https://issues.apache.org/jira/browse/BCEL-243.

Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed, but has 
not been closed.


Thank you,
Mark Roberts

> -Original Message-
> From: Benedikt Ritter [mailto:brit...@apache.org]
> Sent: Monday, June 13, 2016 11:49 PM
> To: Commons Developers List
> Subject: [BCEL] Release Candidate on Thursday
> 
> Hi,
> 
> I'm going to try to create an RC for BCEL 6.0 on friday. Please have a look at
> the current state of the code base and report any issues you see.
> 
> Thank you!
> Benedikt


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

RE: [BCEL6] StackMapTable / StackMapTableEntry gone

2016-06-08 Thread Mark Roberts

There were duplicate versions of these methods with slightly different names.  
We picked the set that seemed to have a better implementation and deleted the 
other two.  This was done as part of the last two pushes to 6.0 (approx. Feb 
2015 and Aug 2015).  A lot of these changes were porting numerous bug fixes and 
enhancements we (the PLSE group at University of Washington) had done to our 
version of BCEL to provide some basic support for StackMaps so our tools 
(Daikon, in particular) could fully support Java 7 and Java 8.  See BCEL issues 
194 through 213 for some general back ground.

On a related note, as a huge user of the current state of BCEL, we have no 
interest in any form of a 5.x release; nor in any release that would require us 
to reedit all of our previous changes in the name of backward compatibility.  
We ARE interested in improved support for Java 8 and Java 9.

Thank you,
Mark Roberts

> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Wednesday, June 08, 2016 4:03 AM
> To: Commons Developers List
> Subject: Re: [BCEL6] StackMapTable / StackMapTableEntry gone
> 
> Let's be clear here.  We are proposing changing the code because someone used 
> a
> SNAPSHOT version and released their code which uses it?  That code was never
> released and I don't know that it's right to bind us to a work-in-progress.  
> It's bad
> enough we have to be saddled forever with the burden of backward 
> compatibility on
> code we release.
> 
> On the other hand, we've done a very poor job of releasing the library, so 
> folks did
> what they had to do to get the new features/fixes.  So, there definitely are 
> two sides
> to this situation.
> 
> On Wed, Jun 8, 2016 at 5:17 AM sebb <seb...@gmail.com> wrote:
> 
> > On 8 June 2016 at 10:01, Andrey Loskutov <losku...@gmx.de> wrote:
> > > On Wednesday 08 June 2016 08:37 Benedikt Ritter wrote:
> > >> Hallo Andrey,
> > >>
> > >> Andrey Loskutov <losku...@gmx.de> schrieb am Mi., 8. Juni 2016 um
> > 09:36 Uhr:
> > >>
> > >> > Hi,
> > >> >
> > >> > I'm following the package rename and trying to fix compile issues
> > >> > with
> > >> > BCEL6 in FindBugs.
> > >> >
> > >> > Before 6.0 we had both StackMap and StackMapTable classes (with
> > >> > StackMapEntry / StackMapTableEntry elements).
> > >> > This was added via https://issues.apache.org/jira/browse/BCEL-92
> > >> > to support Java 6.
> > >> >
> > >> > Now in trunk I see that StackMapTable and  StackMapTableEntry
> > >> > were removed, via https://issues.apache.org/jira/browse/BCEL-248.
> > >> >
> > >> > This causes few compile issues in FindBugs, and I see also no
> > >> > reason
> > why
> > >> > it should be removed either.
> > >> >
> > >> > Unfortunately, Java 1.6 documentation [3] doesn't mentioned
> > >> > neither StackMapTable nor StackMap attributes (or I'm unable to find 
> > >> > it).
> > >> > The official JVM documentation for Java SE 1.7 /1.8 mentions only
> > >> > StackMapTable attribute, see [1,2].
> > >> > StackMap attribute seems to be mentioned in Java ME  specs, see [3].
> > >> > In ASM code I see StackMap seem to be used for classfile versions
> > >> > <
> > 50 (<
> > >> > Java 6) and StackMapTable otherwise.
> > >> >
> > >> > If I understand it right, *both* attributes can appear in class
> > files, and
> > >> > StackMapTable is the one we have to deal with most the time on a
> > standard
> > >> > Java >= 6.
> > >> >
> > >> > So  please can we restore the state where we have StackMapTable /
> > >> > StackMapTableEntry classes , to avoid further confusion and API
> > breakage in
> > >> > BCEL6?
> > >> >
> > >>
> > >> I'm confused. As far as I can tell those classes don't show up in
> > >> the latest Clirr report [1]. I don't understand why they are
> > >> missing. Any
> > idea?
> > >
> > > A-ha, that surprises me too now, but after some software archaeology
> > > it
> > is clear why: the latest official 5.2 release is from June 3 2006,
> > which of course never "officially" supported Java 6 released in 2006-12-23.
> > >
> > > The Java 6 StackMapTable support was added to BCEL 2008 (via
> > > BCEL-92)

RE: [BCEL] What is status of 6.0 release?

2015-11-04 Thread Mark Roberts

It would most definitely be worth it from our point of view (the Daikon
toolset) as we have already rolled our own Java 8 support. Our primary
motivation is that we have been using our own updated version of BCEL for
years and would love to get back to an official release.  Finally, all our
code is open source, we would be happy to share our StackMap support with
BCEL.

Thank you,
Mark

> -Original Message-
> From: sebb [mailto:seb...@gmail.com] 
> Sent: Wednesday, November 04, 2015 6:04 AM
> To: Commons Developers List
> Subject: Re: [BCEL] What is status of 6.0 release?
> 
> On 4 November 2015 at 12:38, Emmanuel Bourg  wrote:
> > Le 04/11/2015 13:21, sebb a écrit :
> >
> >> A fair number of bugs relate to Java8 features - is there 
> any sense 
> >> in releasing an interim version which does not fully support these 
> >> features, but which at least works better for earlier versions of 
> >> Java?
> >
> > I think that an interim release might be fine, as long as 
> implementing 
> > the remaining features is guaranteed not to break the compatibility.
> 
> Well yes, but that's not the question here.
> 
> Is it actually *worth* the effort of producing an interim 
> release that does not fully support Java8?
> Or would that not actually be useful?
> I'm asking this because it looks like adding full Java8 
> support is proving very time-consuming.
> 
> > Emmanuel Bourg
> >
> >
> > 
> -
> > 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
> 
> 


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

[BCEL] What is status of 6.0 release?

2015-11-03 Thread Mark Roberts

I was actively involved in helping with BCEL 6.0 - but everything seems to have 
gone dark for the last couple of months.

So, what's going on?

Thank you,
Mark Roberts



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

[BCEL] deprecation of getClassName in generic/FieldOrMethod

2015-09-04 Thread Mark Roberts

I read and understood the comment as to the reasoning, but the problem is the 
shared code nature of FieldOrMethod.  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.

Thanks,
Mark


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

RE: BCEL design goals? (was RE: [jira] [Commented] (BCEL-233) The access_flags field in AccessFlags class should be final)

2015-08-17 Thread Mark Roberts

That's a little tricky to answer.  As one example, look at 
generic/LocalVariableInstruction.  Neither the index or opcode is final.  A 
user needs to be able to insert new local variables and hence they need to be 
able to modify the local variable offset (index).  And 'beneath the covers' 
BCEL will modify the opcode if the index changes from one side of the single 
byte opcode to the other.  E.g., it will change an 'aload_n' to an 'aload'; 
thus changing both the opcode and the length of the instruction.

As a general rule, you might try to say you can only replace an instruction 
rather than modify it.  Personally, I think that is too restrictive.


-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Sunday, August 16, 2015 5:17 AM
To: Commons Developers List
Subject: Re: BCEL design goals? (was RE: [jira] [Commented] (BCEL-233) The 
access_flags field in AccessFlags class should be final)

I think it's still an error to change certain aspects of an Instruction class.
For example, the opcode and length are fixed for a particular instruction type.



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

BCEL design goals? (was RE: [jira] [Commented] (BCEL-233) The access_flags field in AccessFlags class should be final)

2015-08-14 Thread Mark Roberts

I hope this doesn't come across as too strident, but working towards a 
resolution of this particular issue has got me thinking about how I use BCEL - 
and this seems like a good time/place to clarify my understanding of BCEL's 
purpose.  

Simply stated, it is my belief that a client should be able to read and/or 
write any member, field, flag, or what have you in a .class file.

Is that assuming too much?  Are there any intentional restrictions?

Thanks,
Mark


-Original Message-
From: Sebb (JIRA) [mailto:j...@apache.org] 
Sent: Friday, August 14, 2015 3:30 PM
To: mar...@cs.washington.edu
Subject: [jira] [Commented] (BCEL-233) The access_flags field in AccessFlags 
class should be final


[ 
https://issues.apache.org/jira/browse/BCEL-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14697872#comment-14697872
 ] 

Sebb commented on BCEL-233:
---

OK, have you got any sample code that could be used as test cases?

 The access_flags field in AccessFlags class should be final
 ---

 Key: BCEL-233
 URL: https://issues.apache.org/jira/browse/BCEL-233
 Project: Commons BCEL
  Issue Type: Improvement
Reporter: Sebb
 Fix For: 6.0


 The access_flags field in the AccessFlags class should be final.
 It is currently not set by any other classes outside their constructors.
 The public setters - e.g. isPrivate(boolean) - are not used and should be 
 deleted. [Apart from that, their names are really confusing.]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


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

RE: [BCEL] 6.0 RC4

2015-08-13 Thread Mark Roberts

I would like to update some of my proposed fixes and lobby for their inclusion 
in the next release of BCEL.  To that end I presume I should be comparing my 
changes with the source in the RC4 tag as opposed to the trunk.  Is that 
correct?

Thank you,
Mark Roberts






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

RE: [BCEL] 6.0 RC4

2015-08-13 Thread Mark Roberts

(Thank you - I will use the trunk.)

I have about 10 open issues that have received no comments or attention (that I 
am aware of) in the last 6 months or so.  As I noted in my introduction 
(attached) several of our release tools use the BCEL library for class file 
manipulation.  We continue to release updates every month and it would be nice 
to have our changes adopted so that we can release an 'official' BCEL, rather 
than our private branch.  To that end, I am unclear as to the procedure used to 
decide what is (or is not) included in a release.   I certainly have time 
available to help out.  Is there some way I can be of more assistance in this 
process?

Thank you,
Mark

-Original Message-
From: Gary Gregory [mailto:garydgreg...@gmail.com] 
Sent: Thursday, August 13, 2015 8:17 AM
To: Commons Developers List
Subject: Re: [BCEL] 6.0 RC4

I would work against the latest from trunk.

Gary

On Wed, Aug 12, 2015 at 2:43 PM, Mark Roberts mar...@cs.washington.edu
wrote:

 I would like to update some of my proposed fixes and lobby for their 
 inclusion in the next release of BCEL.  To that end I presume I should 
 be comparing my changes with the source in the RC4 tag as opposed to 
 the trunk.  Is that correct?

 Thank you,
 Mark Roberts






 -
 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 http://www.manning.com/bauer3/ JUnit in Action, 
Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
---BeginMessage---
My name is Mark Roberts and I work in the Programming Languages and Software 
Engineering group (PLSE) at the University of Washington. 
(http://www.cs.washington.edu/research/plse)

Our team develops and supports a number of open source tools.  One of the 
main ones, Daikon  (http://plse.cs.washington.edu/daikon/) makes extensive 
use of BCEL to manipulate Java class files.  We have been using BCEL since 
2001 and have made a few changes along the way.  I have just completed 
re-merging our BCEL source tree with a fairly recent mainline version 
(r1646789 2014-12-19).

I have exchanged email with Torsten Curdt and he suggested I join this 
mailing list as a first step in sharing our changes and fixes.

Thank you,
Mark


---End Message---

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

RE: [BCEL] Java version

2015-08-13 Thread Mark Roberts

I think 7 is fine.  I would be hesitant to go all the way to 8 at this time.

Thanks,
Mark

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Thursday, August 13, 2015 11:48 AM
To: Commons Developers List
Subject: Re: [BCEL] Java version

On 13 August 2015 at 17:58, Gary Gregory garydgreg...@gmail.com wrote:
 The POM sets the source version to Java 1.5 but the code does not 
 compile on Java 1.5.

 I say we just move the req to java 7 or 8 and move on.

I would be OK with Java 7 as a minimum.

I realise that I normally argue for the minimum Java version, but BCEL is 
different from most of the other Commons components.

It is likely to be mainly used in Maven or stand-alone applications, and it 
seems likely that any usage will be on a host that can readily be upgraded to 
at least Java 7.

This is not the case for many of the other Commons components which are likely 
to be deeply embedded in large complex systems where Java upgrades are much 
harder to test and implement.

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence 
 with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit 
 in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 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: [bcel] PLSE changes to BCEL

2015-02-19 Thread Mark Roberts

I am going to try to spend most of today working on BCEL; I am currently 
looking at 195, 200,203,208 and 210.

Mark



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

RE: [bcel] PLSE changes to BCEL

2015-02-05 Thread Mark Roberts

I've probably missed something - but I think I've got all of our  (PLSE)
changes into the jira database.

I'm going to look at the signatureToString issue now.

Thanks to everybody who helped me along the way...
 
Mark




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

RE: [bcel] PLSE changes to BCEL

2015-02-04 Thread Mark Roberts

Thank you for setting these up for me!  I am going to attach my diffs today.

I would really like to see this material in 6.0.  Most all of the changes are 
bug fixes or feature enhancements (in the case of StackMap support).  They all, 
in my opinion, make BCEL a better product.   And on a personal note, given that 
this is the first update in forever (nine years?) - if we don't merge now, how 
much longer will I continue to be out of sync with the mainline?

Thank you,
Mark
 
-Original Message-
From: benjamin.j.mcc...@gmail.com [mailto:benjamin.j.mcc...@gmail.com] On 
Behalf Of Ben McCann
Sent: Wednesday, February 04, 2015 10:49 AM
To: Commons Developers List
Subject: Re: [bcel] PLSE changes to BCEL

BCEL-79 has not been reopened yet

The new issues have been filed as BCEL-187 
https://issues.apache.org/jira/browse/BCEL-187 through BCEL-193 
https://issues.apache.org/jira/browse/BCEL-193.

Are any of these blocking the 6.0 release or do you think we might be able to 
cut that now?

Thanks,
Ben


On Tue, Jan 27, 2015 at 1:58 AM, Emmanuel Bourg ebo...@apache.org wrote:

 Le 27/01/2015 05:36, Mark Roberts a écrit :

  To repeat - constructing the local variables from the local variable
 types
  is totally bogus.   I have no idea how that fixed the original problem
 but
  it is clearly incorrect.

 Ok, could you reopen BCEL-79 and copy your comment in JIRA please? 
 Would you be able to craft a test case demonstrating the issue?

 Emmanuel Bourg


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




--
about.me/benmccann


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

RE: [bcel] PLSE changes to BCEL

2015-02-04 Thread Mark Roberts

Sorry - I clearly misunderstood Ben's email about issues 187-193 (the reference 
to issue 79 made me think the mail was specific to me). 

However, my comments about 6.0 are still valid and I will open new issues for 
my work immediately.

Thank you, Mark


-Original Message-
From: Mark Roberts [mailto:mar...@cs.washington.edu] 
Sent: Wednesday, February 04, 2015 11:09 AM
To: 'Commons Developers List'
Subject: RE: [bcel] PLSE changes to BCEL

Thank you for setting these up for me!  I am going to attach my diffs today.

I would really like to see this material in 6.0.  Most all of the changes are 
bug fixes or feature enhancements (in the case of StackMap support).  They all, 
in my opinion, make BCEL a better product.   And on a personal note, given that 
this is the first update in forever (nine years?) - if we don't merge now, how 
much longer will I continue to be out of sync with the mainline?

Thank you,
Mark
 
-Original Message-
From: benjamin.j.mcc...@gmail.com [mailto:benjamin.j.mcc...@gmail.com] On 
Behalf Of Ben McCann
Sent: Wednesday, February 04, 2015 10:49 AM
To: Commons Developers List
Subject: Re: [bcel] PLSE changes to BCEL

BCEL-79 has not been reopened yet

The new issues have been filed as BCEL-187 
https://issues.apache.org/jira/browse/BCEL-187 through BCEL-193 
https://issues.apache.org/jira/browse/BCEL-193.

Are any of these blocking the 6.0 release or do you think we might be able to 
cut that now?

Thanks,
Ben


On Tue, Jan 27, 2015 at 1:58 AM, Emmanuel Bourg ebo...@apache.org wrote:

 Le 27/01/2015 05:36, Mark Roberts a écrit :

  To repeat - constructing the local variables from the local variable
 types
  is totally bogus.   I have no idea how that fixed the original problem
 but
  it is clearly incorrect.

 Ok, could you reopen BCEL-79 and copy your comment in JIRA please? 
 Would you be able to craft a test case demonstrating the issue?

 Emmanuel Bourg


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




--
about.me/benmccann


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

RE: [bcel] PLSE changes to BCEL

2015-02-04 Thread Mark Roberts

I would like to reopen BCEL-79, but I'm new to JIRA and I can't figure out how 
to do it.Reopen does not appear to be one of the choices on the drop down 
tools menu.  Could someone let me know how to do this?  

Thank you,
Mark Roberts


-Original Message-
From: benjamin.j.mcc...@gmail.com [mailto:benjamin.j.mcc...@gmail.com] On 
Behalf Of Ben McCann
Sent: Wednesday, February 04, 2015 10:49 AM
To: Commons Developers List
Subject: Re: [bcel] PLSE changes to BCEL

BCEL-79 has not been reopened yet

The new issues have been filed as BCEL-187 
https://issues.apache.org/jira/browse/BCEL-187 through BCEL-193 
https://issues.apache.org/jira/browse/BCEL-193.

Are any of these blocking the 6.0 release or do you think we might be able to 
cut that now?

Thanks,
Ben


On Tue, Jan 27, 2015 at 1:58 AM, Emmanuel Bourg ebo...@apache.org wrote:

 Le 27/01/2015 05:36, Mark Roberts a écrit :

  To repeat - constructing the local variables from the local variable
 types
  is totally bogus.   I have no idea how that fixed the original problem
 but
  it is clearly incorrect.

 Ok, could you reopen BCEL-79 and copy your comment in JIRA please? 
 Would you be able to craft a test case demonstrating the issue?

 Emmanuel Bourg


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




--
about.me/benmccann


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

RE: [bcel] PLSE changes to BCEL

2015-01-26 Thread Mark Roberts

Good question.  When I started work here (at PLSE) in Jan 2013, we had been 
using BCEL for some time.  We had not released a version of our product in 
about three years and one of my tasks was to get back to making regular 
releases of the Daikon toolset.  So in about May of 2013 I picked up the latest 
Revision of BCEL.  I got it working and noticed we had a few existing 
differences from the mainline that had apparently been there for quite some 
time.  As time went on,  I found and fixed a couple of problems with BCEL.  I 
noticed that after several months there had been no activity on the product at 
all.  I sent email to one of the developers and was told that the project was 
in limbo and 5.2 might be the last release.  I promised to send what changes I 
had, but never got around to it.  Over the next year I noticed a few checkins, 
but no signs of a release.  Recently, I was encouraged by my supervisor 
(Professor Michael Ernst) to make a better effort at sharing our work.  I was 
quite taken by surprise by the amount of work in the last 6 months or so on the 
project.  So I got the latest version of BCEL, went through the integration 
process and here we are.

So, if the intention is to start making regular releases of BCEL again, I'm all 
for it and more than willing to help. 

Mark

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On 
Behalf Of James Carman
Sent: Monday, January 26, 2015 10:20 AM
To: Commons Developers List
Subject: Re: [bcel] PLSE changes to BCEL

Out of curiosity, what was the reason you rolled your own as opposed to 
engaging with the community on these changes?


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

[bcel] PLSE changes to BCEL

2015-01-26 Thread Mark Roberts

 different.  
Trying not to be too biased, I believe our method is better.  One of the larger 
differences is your decision to add the abstract class NameSignatureMethod 
between FieldOrMethod and CPInstruction and then have InvokeDynamic extend from 
that instead of from InvokeInstruction.  To me this seems wrong.   In addition 
to forcing InvokeDynamic to duplicate all the methods from InvokeInstruction 
and FieldOrMethod, it is awkward that it is the only form of the Invoke 
Instruction that doesn't derive from InvokeInstruction. (‘ID’ and ‘BM’ as well.)

‘B’, ‘H’, and ‘LV’ are important bug fixes.

I not sure why you chose not to complete the change from DataInputStream to 
DataInput (‘I’).  This was another item we did here at PLSE independent of your 
work.  Going all the way is nice, because tools that use BCEL can then backup 
and reprocess the input class file.

A lot of the ‘TS’ changes were to make the BCEL output look more like the 
‘javap’ output; you may not care, but this was useful to some of our clients.

Sorry for length of post and amount of information.  We can divide into 
separate threads If you wish.

Mark


-Original Message-
From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On Behalf Of Emmanuel 
Bourg
Sent: Friday, January 23, 2015 2:11 PM
To: Commons Developers List
Subject: Re: [bcel] new to list - introduction

Le 23/01/2015 20:55, Mark Roberts a écrit :
 My name is Mark Roberts and I work in the Programming Languages and 
 Software Engineering group (PLSE) at the University of Washington. 
 (http://www.cs.washington.edu/research/plse)
 
 Our team develops and supports a number of open source tools.  One of the 
 main ones, Daikon  (http://plse.cs.washington.edu/daikon/) makes extensive 
 use of BCEL to manipulate Java class files.  We have been using BCEL since 
 2001 and have made a few changes along the way.  I have just completed 
 re-merging our BCEL source tree with a fairly recent mainline version 
 (r1646789 2014-12-19).  
 
 I have exchanged email with Torsten Curdt and he suggested I join this 
 mailing list as a first step in sharing our changes and fixes.

Hi Mark and welcome to Apache Commons. We are about to release BCEL 6.0 but 
it's still time to commit some minor changes. I plan to merge the recent 
verifier improvement contributed by Jérôme Leroux and cut a new release 
candidate shortly after.

What kind of improvements would you like to contribute? We can start discussing 
them on the list and then open related issues in JIRA.

Emmanuel Bourg


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

RE: [bcel] PLSE changes to BCEL

2015-01-26 Thread Mark Roberts

In our opinion, the fix is worse than the disease.  Here are the comments
from our version:

  The following piece of code is new since our 5.2 based version.
   It was added in revision 524610 on 2007-04-01, more information is at:
   http://issues.apache.org/bugzilla/show_bug.cgi?id=39695 (now BCEL-79)
   However, it seems quite wrong to me and I have no idea how it solved the
bug.
   There is no requirement for there to be as many LocalVariableTypeTable
entries
   as there are LocalVariables.  In fact, there will almost always be fewer.
So
   deleting the local variables and reconstructing them from types makes no
sense.
   Was it a bad cut and paste job from above and meant to reconstruct the
types
   table?  Then how did it fix the bug?  More likely, the test case had the
same
   number of vars and types.  If so, the correct code would seem to be only
modify
   those local vars that have a matching type.  I cannot figure out what was
intended
   so I'm just going to comment the whole thing out.   (markro)

To repeat - constructing the local variables from the local variable types
is totally bogus.   I have no idea how that fixed the original problem but
it is clearly incorrect.

Mark

 -Original Message-
 From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On 
 Behalf Of Emmanuel Bourg

 Isn't BCEL-79 already fixed?

RE: [bcel] PLSE changes to BCEL

2015-01-26 Thread Mark Roberts

I understand the goal of trying to reuse instructions - an 'iadd' is the
same as any other 'iadd'.  However,  one 'goto 50' is not the same as
another 'goto 50' due to the way Targeters are implemented.  If branch
instructions are reused, then only one entry gets put on the Targeter list.
So when some api is used to modify the instruction list and location 50
becomes location 52 ONLY ONE of the branches gets updated. A very bad thing.
So unless you modify the hash to special case branch instructions (and there
might be other instructions needing special treatment as well) its broken.
We fixed it by simply commenting the hash out to make things like they used
to be and all works great.

Which takes us to another question I was going to ask - is there a BCEL test
suite?  'mvn verify' is ok for build verification - but it doesn't begin to
cover the bases of what the api can do - especially in the area of code
modification.

Mark

 -Original Message-
 From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On 
 Behalf Of Emmanuel Bourg
 Sent: Monday, January 26, 2015 4:14 PM
 
  I was surprised by 'U' as that change had a huge side 
 effect, possibly due to a design flaw in how Targeters work; 
 I was unable to find any discussion in your archives.
 
 Could you elaborate a bit on this change?
 


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

[bcel] new to list - introduction

2015-01-23 Thread Mark Roberts

My name is Mark Roberts and I work in the Programming Languages and Software 
Engineering group (PLSE) at the University of Washington. 
(http://www.cs.washington.edu/research/plse) 

Our team develops and supports a number of open source tools.  One of the main 
ones, Daikon  (http://plse.cs.washington.edu/daikon/) makes extensive use of 
BCEL to manipulate Java class files.  We have been using BCEL since 2001 and 
have made a few changes along the way.  I have just completed re-merging our 
BCEL source tree with a fairly recent mainline version (r1646789 2014-12-19).  

I have exchanged email with Torsten Curdt and he suggested I join this mailing 
list as a first step in sharing our changes and fixes.

Thank you,
Mark



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

68 matches

Mail list logo