Release BCEL 6.1?

[Andreas Sewe]

Hi,

would it be possible to release a new version of BCEL? The last release
(6.0) was over a year ago (in July 2016 [1]).

As a committer to the SpotBugs project (the successor of FindBugs), I
would like to see BCEL 6.1 out in the near future [2], as we suffer from
bug BCEL-284 [3]. Unfortunately, our last request for a BCEL 6.1 release
wasn't heard [4] and we are now considering forking BCEL [5] -- which I
consider to be a measure of last resort.

Thus, it would be great if we could see an official BCEL 6.1 release.

If you need any assistance or additional testing, I'd be happy to help out.

Best wishes,

Andreas

[1]

[2] 
[3] 
[4]

[5] 

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature

Re: Release BCEL 6.1?

[Benedikt Ritter]

Hello Andreas,

> Am 25.08.2017 um 15:24 schrieb Andreas Sewe :
> 
> Hi,
> 
> would it be possible to release a new version of BCEL? The last release
> (6.0) was over a year ago (in July 2016 [1]).
> 
> As a committer to the SpotBugs project (the successor of FindBugs), I
> would like to see BCEL 6.1 out in the near future [2], as we suffer from
> bug BCEL-284 [3]. Unfortunately, our last request for a BCEL 6.1 release
> wasn't heard [4] and we are now considering forking BCEL [5] -- which I
> consider to be a measure of last resort.
> 
> Thus, it would be great if we could see an official BCEL 6.1 release.
> 
> If you need any assistance or additional testing, I'd be happy to help out.

I’ll have a look into this and come back to you. Probably on Sunday since I’ll 
be on the train then and will have some time.

Cheers,
Benedikt

> 
> Best wishes,
> 
> Andreas
> 
> [1]
> 
> [2] 
> [3] 
> [4]
> 
> [5] 
> 
> -- 
> Codetrails GmbH
> The best code possible
> 
> Robert-Bosch-Str. 7, 64293 Darmstadt
> Phone: +49-6151-276-7092
> Mobile: +49-170-811-3791
> http://www.codetrails.com/
> 
> Managing Director: Dr. Marcel Bruch
> Handelsregister: Darmstadt HRB 91940
> 


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

Re: Release BCEL 6.1?

[Andreas Sewe]

Hello Benedikt,

> I’ll have a look into this and come back to you. Probably on Sunday since 
> I’ll be on the train then and will have some time.

sounds good. Thank you for looking into this.

Best wishes,

Andreas

-- 
Codetrails GmbH
The best code possible

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940



signature.asc
Description: OpenPGP digital signature

Re: Release BCEL 6.1?

[Gary Gregory]

On Fri, Aug 25, 2017 at 8:53 AM, Benedikt Ritter  wrote:

> Hello Andreas,
>
> > Am 25.08.2017 um 15:24 schrieb Andreas Sewe  >:
> >
> > Hi,
> >
> > would it be possible to release a new version of BCEL? The last release
> > (6.0) was over a year ago (in July 2016 [1]).
> >
> > As a committer to the SpotBugs project (the successor of FindBugs), I
> > would like to see BCEL 6.1 out in the near future [2], as we suffer from
> > bug BCEL-284 [3]. Unfortunately, our last request for a BCEL 6.1 release
> > wasn't heard [4] and we are now considering forking BCEL [5] -- which I
> > consider to be a measure of last resort.
> >
> > Thus, it would be great if we could see an official BCEL 6.1 release.
> >
> > If you need any assistance or additional testing, I'd be happy to help
> out.
>
> I’ll have a look into this and come back to you. Probably on Sunday since
> I’ll be on the train then and will have some time.
>

Great news! Thank you B!

Gary

>
> Cheers,
> Benedikt
>
> >
> > Best wishes,
> >
> > Andreas
> >
> > [1]
> >  apache.bcel%22%20AND%20a%3A%22bcel%22>
> > [2] 
> > [3] 
> > [4]
> >  201612.mbox/ajax/%3CCAO1eWSCCQR%3Du0anpeXc6AixKfRZuSq6T2BPDYYj
> aPp%3Dh_S%2BN6Q%40mail.gmail.com%3E>
> > [5]  issuecomment-323340124>
> >
> > --
> > Codetrails GmbH
> > The best code possible
> >
> > Robert-Bosch-Str. 7, 64293 Darmstadt
> > Phone: +49-6151-276-7092
> > Mobile: +49-170-811-3791
> > http://www.codetrails.com/
> >
> > Managing Director: Dr. Marcel Bruch
> > Handelsregister: Darmstadt HRB 91940
> >
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Re: [CSV] CSVMutableRecord

[nitin mahendru]

Hi Everyone,

Any decision on this yet ?
Thanks

Nitin




On Mon, Aug 21, 2017 at 2:51 PM nitin mahendru 
wrote:

> Just another follow up. Anything new ?
>
> -Nitin
>
>
>
>
> On Thu, Aug 17, 2017 at 10:58 AM Gary Gregory 
> wrote:
>
>> Not yet ;-)
>>
>> On Aug 17, 2017 11:34, "nitin mahendru" 
>> wrote:
>>
>> > Hi All,
>> >
>> > Any consensus on this ?
>> >
>> > -Nitin
>> >
>> >
>> >
>> >
>> > On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory 
>> > wrote:
>> >
>> > > On Tue, Aug 15, 2017 at 5:32 PM, Gilles > >
>> > > wrote:
>> > >
>> > > > On Tue, 15 Aug 2017 22:52:32 +, nitin mahendru wrote:
>> > > >
>> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > > >>
>> > > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > > >>> > > > >>>
>> > >  wrote:
>> > > 
>> > > >>>
>> > > >>> How about having a state in the class itself which says that it's
>> > >  mutable
>> > >  or not.
>> > >  If we call a setter on an immutable then it throws an exception.
>> > >  By default the records are immutable and you need to make them
>> > >  mutable
>> > >  using a new API.
>> > > 
>> > > >>>
>> > > >> A code example would be useful...
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> Below is the pull request I added.
>> > > >> https://github.com/apache/commons-csv/pull/21
>> > > >>
>> > > >
>> > > > As I indicated in the previous message, this is functionally
>> > > > breaking. [I'm diverting this discussion over to the "dev"
>> > > > mailing list.]
>> > > >
>> > >
>> > > Saying that making record mutable is "breaking" is a bit unfair when
>> we
>> > do
>> > > NOT document the mutability of the class in the first place.
>> > >
>> > > Gary
>> > >
>> > >
>> > > >
>> > > > The following should be an interesting read:
>> > > >   http://markmail.org/message/6ytvmxvy2ndsfp7h
>> > > >
>> > > >
>> > > > Regards,
>> > > > Gilles
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
>> gil...@harfang.homelinux.org
>> > >
>> > > >> wrote:
>> > > >>
>> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
>> > > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
>> > > >>> > > > > >>> >> wrote:
>> > > >>> >
>> > > >>> >> How about having a state in the class itself which says that
>> it's
>> > > >>> >> mutable
>> > > >>> >> or not.
>> > > >>> >> If we call a setter on an immutable then it throws an
>> exception.
>> > > >>> >> By default the records are immutable and you need to make them
>> > > >>> >> mutable
>> > > >>> >> using a new API.
>> > > >>>
>> > > >>> A code example would be useful...
>> > > >>>
>> > > >>> >> pros: Saves memory, Keeps the immutability benefits
>> > > >>>
>> > > >>> What kind of usage are you considering that a single transient
>> > > >>> record matters (as compared to the ~300 MB of the JVM itself...)?
>> > > >>>
>> > > >>> >> cons: people using "mutable" records need to be careful.(While
>> > > >>> >> threading
>> > > >>> >> maybe)
>> > > >>> >>
>> > > >>> >
>> > > >>> > Interesting idea!
>> > > >>> >
>> > > >>> > But I think I like the idea of a subclass better if we are
>> going to
>> > > >>> > split
>> > > >>> > the behavior b/w mutable and immutable.
>> > > >>>
>> > > >>> Once you have a subclass that is able to modify the state of
>> > > >>> its parent, it's a mutable object. Period.
>> > > >>> There is no such thing as a "split".
>> > > >>>
>> > > >>> >
>> > > >>> > For my money and the KISS principle, I would just add the put
>> > method
>> > > >>> > in
>> > > >>> > CSVRecord.
>> > > >>>
>> > > >>> Then, any use that assumes immutability will be broken.
>> > > >>>
>> > > >>>
>> > > >>> Gilles
>> > > >>>
>> > > >>>
>> > > >>> > Gary
>> > > >>> >
>> > > >>> >>
>> > > >>> >> -Nitin
>> > > >>> >>
>> > > >>> >>
>> > > >>> >>
>> > > >>> >>
>> > > >>> >> On Tue, Aug 15, 2017 at 9:01 AM Gilles
>> > > >>> >> 
>> > > >>> >> wrote:
>> > > >>> >>
>> > > >>> >> > On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote:
>> > > >>> >> > > That looks odd to me. What comes up for me is the use case
>> > where
>> > > >>> >> I
>> > > >>> >> > > want to
>> > > >>> >> > > ETL a file of 10,000,000 records and update, say, one
>> column.
>> > If
>> > > >>> >> am
>> > > >>> >> > > forced
>> > > >>> >> > > to create a brand new record for every record read, that
>> would
>> > > >>> >> be a
>> > > >>> >> > > shame.
>> > > >>> >> >
>> > > >>> >> > Why?
>> > > >>> >> >
>> > > >>> >> > > If I had a mutable record, I could just keep on updating it
>> > and
>> > > >>> >> using
>> > > >>> >> > > it to
>> > > >>> >> > > write each row. Read record, update it, write record. No
>> extra
>> > > >>> >> memory
>> > > >>> >> > > needed.
>> > > >>> >> >
>> > > >>> >> > How is the size of 1 additional record going to matter
>> compared
>> > to
>> > > >>> >> the
>> > > >>> >> > size of the whole program?
>> > > >>> >> >
>> > > >>> >> > > Either we can make the current record mutable (what's the
>> > harm?)
>> > > >>> >> or
>> > > >>> >> >

Re: [CSV] CSVMutableRecord

[Gary Gregory]

On Fri, Aug 25, 2017 at 11:08 AM, nitin mahendru  wrote:

> Hi Everyone,
>
> Any decision on this yet ?
>

Not yet. Needs a bit more stewing and brewing...

Gary


> Thanks
>
> Nitin
>
>
>
>
> On Mon, Aug 21, 2017 at 2:51 PM nitin mahendru  >
> wrote:
>
> > Just another follow up. Anything new ?
> >
> > -Nitin
> >
> >
> >
> >
> > On Thu, Aug 17, 2017 at 10:58 AM Gary Gregory 
> > wrote:
> >
> >> Not yet ;-)
> >>
> >> On Aug 17, 2017 11:34, "nitin mahendru" 
> >> wrote:
> >>
> >> > Hi All,
> >> >
> >> > Any consensus on this ?
> >> >
> >> > -Nitin
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Aug 15, 2017 at 4:43 PM Gary Gregory 
> >> > wrote:
> >> >
> >> > > On Tue, Aug 15, 2017 at 5:32 PM, Gilles <
> gil...@harfang.homelinux.org
> >> >
> >> > > wrote:
> >> > >
> >> > > > On Tue, 15 Aug 2017 22:52:32 +, nitin mahendru wrote:
> >> > > >
> >> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >> > > >>
> >> > > >>> On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >> > > >>>  >> > > >>>
> >> > >  wrote:
> >> > > 
> >> > > >>>
> >> > > >>> How about having a state in the class itself which says that
> it's
> >> > >  mutable
> >> > >  or not.
> >> > >  If we call a setter on an immutable then it throws an
> exception.
> >> > >  By default the records are immutable and you need to make them
> >> > >  mutable
> >> > >  using a new API.
> >> > > 
> >> > > >>>
> >> > > >> A code example would be useful...
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> Below is the pull request I added.
> >> > > >> https://github.com/apache/commons-csv/pull/21
> >> > > >>
> >> > > >
> >> > > > As I indicated in the previous message, this is functionally
> >> > > > breaking. [I'm diverting this discussion over to the "dev"
> >> > > > mailing list.]
> >> > > >
> >> > >
> >> > > Saying that making record mutable is "breaking" is a bit unfair when
> >> we
> >> > do
> >> > > NOT document the mutability of the class in the first place.
> >> > >
> >> > > Gary
> >> > >
> >> > >
> >> > > >
> >> > > > The following should be an interesting read:
> >> > > >   http://markmail.org/message/6ytvmxvy2ndsfp7h
> >> > > >
> >> > > >
> >> > > > Regards,
> >> > > > Gilles
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >> On Tue, Aug 15, 2017 at 11:17 AM Gilles <
> >> gil...@harfang.homelinux.org
> >> > >
> >> > > >> wrote:
> >> > > >>
> >> > > >> On Tue, 15 Aug 2017 12:02:20 -0600, Gary Gregory wrote:
> >> > > >>> > On Tue, Aug 15, 2017 at 10:38 AM, nitin mahendru
> >> > > >>> >  >> > > >>> >> wrote:
> >> > > >>> >
> >> > > >>> >> How about having a state in the class itself which says that
> >> it's
> >> > > >>> >> mutable
> >> > > >>> >> or not.
> >> > > >>> >> If we call a setter on an immutable then it throws an
> >> exception.
> >> > > >>> >> By default the records are immutable and you need to make
> them
> >> > > >>> >> mutable
> >> > > >>> >> using a new API.
> >> > > >>>
> >> > > >>> A code example would be useful...
> >> > > >>>
> >> > > >>> >> pros: Saves memory, Keeps the immutability benefits
> >> > > >>>
> >> > > >>> What kind of usage are you considering that a single transient
> >> > > >>> record matters (as compared to the ~300 MB of the JVM
> itself...)?
> >> > > >>>
> >> > > >>> >> cons: people using "mutable" records need to be
> careful.(While
> >> > > >>> >> threading
> >> > > >>> >> maybe)
> >> > > >>> >>
> >> > > >>> >
> >> > > >>> > Interesting idea!
> >> > > >>> >
> >> > > >>> > But I think I like the idea of a subclass better if we are
> >> going to
> >> > > >>> > split
> >> > > >>> > the behavior b/w mutable and immutable.
> >> > > >>>
> >> > > >>> Once you have a subclass that is able to modify the state of
> >> > > >>> its parent, it's a mutable object. Period.
> >> > > >>> There is no such thing as a "split".
> >> > > >>>
> >> > > >>> >
> >> > > >>> > For my money and the KISS principle, I would just add the put
> >> > method
> >> > > >>> > in
> >> > > >>> > CSVRecord.
> >> > > >>>
> >> > > >>> Then, any use that assumes immutability will be broken.
> >> > > >>>
> >> > > >>>
> >> > > >>> Gilles
> >> > > >>>
> >> > > >>>
> >> > > >>> > Gary
> >> > > >>> >
> >> > > >>> >>
> >> > > >>> >> -Nitin
> >> > > >>> >>
> >> > > >>> >>
> >> > > >>> >>
> >> > > >>> >>
> >> > > >>> >> On Tue, Aug 15, 2017 at 9:01 AM Gilles
> >> > > >>> >> 
> >> > > >>> >> wrote:
> >> > > >>> >>
> >> > > >>> >> > On Tue, 15 Aug 2017 09:49:04 -0600, Gary Gregory wrote:
> >> > > >>> >> > > That looks odd to me. What comes up for me is the use
> case
> >> > where
> >> > > >>> >> I
> >> > > >>> >> > > want to
> >> > > >>> >> > > ETL a file of 10,000,000 records and update, say, one
> >> column.
> >> > If
> >> > > >>> >> am
> >> > > >>> >> > > forced
> >> > > >>> >> > > to create a brand new record for every record read, that
> >> would
> >> > > >>> >> be a
> >> > > >>> >> > > shame.
> >> > > >>> >> >
> >> > > >>> >> > Why?
> >> > > >>> >> >
> >> > > >>> >> > > If I had a mutable record,