Re: [codec]

[Gary Gregory]

The required version is Java 8 minimum, but we do use other LTS versions to
test builds in GitHub but this is not a guarantee or endorsement that the
Java version you use from whatever vendor you use will work, your testing
will reveal that. We do not "support" Java 11 or 17 in the traditional
sense you might be used from commercial vendors, we act on a best effort
and voluntary basis.

Gary

On Tue, Jul 19, 2022, 11:50 Abhishek Kant Rattan
 wrote:

> Hello team,
>
> Version 1.15 is supported with Java 11 or Java 17?
>
>
> Thanks & Regards,
> [http://mediabank.ericsson.net/internet-media/Email_logo_Ericsson.png]<
> http://www.ericsson.com/>
>
> Abhishek Kant Rattan
> Senior Engineer
> BDGS SA BSS PDU BSS PDG EC GG Support
> Mobile: +91 8586980609
> abhishek.kant.rat...@ericsson.com
>
> ericsson.com
>
> [http://mediabank.ericsson.net/internet-media/Email_Message.gif]<
> http://www.ericsson.com/current_campaign>
>
> Our commitment to Technology for Good<
> http://www.ericsson.com/thecompany/sustainability-corporateresponsibility>
> and Diversity and Inclusion<
> http://www.ericsson.com/thecompany/diversity-inclusion> contributes to
> positive change.
> Follow us on: Facebook LinkedIn<
> https://www.linkedin.com/company/ericsson> Twitter<
> https://twitter.com/Ericsson>
>
> This communication is confidential. Our email terms:
> www.ericsson.com/en/legal/privacy/email-disclaimer
>
>

Re: [codec]

[Bernd Eckenfels]

The minimum version required is java 7, I don’t see open issues with later 
versions. If you encounter problems, feel free to report them.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Abhishek Kant Rattan 
Gesendet: Tuesday, July 19, 2022 4:53:27 PM
An: user@commons.apache.org 
Betreff: [codec]

Hello team,

Version 1.15 is supported with Java 11 or Java 17?


Thanks & Regards,
[http://mediabank.ericsson.net/internet-media/Email_logo_Ericsson.png]

Abhishek Kant Rattan
Senior Engineer
BDGS SA BSS PDU BSS PDG EC GG Support
Mobile: +91 8586980609
abhishek.kant.rat...@ericsson.com

ericsson.com

[http://mediabank.ericsson.net/internet-media/Email_Message.gif]

Our commitment to Technology for 
Good 
and Diversity and 
Inclusion contributes 
to positive change.
Follow us on: Facebook 
LinkedIn 
Twitter

This communication is confidential. Our email terms: 
www.ericsson.com/en/legal/privacy/email-disclaimer

Re: [codec]

[Bernd Eckenfels]

Hello,

Apache a commons are a number of community supported open source projects, 
there is no guaranteed support provided. The good thing is you can always join 
the project and help.

Having said that, 1.15 is the current released version, so if a new version is 
released you only need to upgrade to get the fixes and new features.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Abhishek Kant Rattan 
Gesendet: Dienstag, Juli 19, 2022 5:51 PM
An: user@commons.apache.org 
Betreff: [codec]

Hello Team,

We want to know the End of support and End of life for apache Common codec 
version  1.15.


Thanks & Regards,
[http://mediabank.ericsson.net/internet-media/Email_logo_Ericsson.png]

Abhishek Kant Rattan
Senior Engineer
BDGS SA BSS PDU BSS PDG EC GG Support
Mobile: +91 8586980609
abhishek.kant.rat...@ericsson.com

ericsson.com

[http://mediabank.ericsson.net/internet-media/Email_Message.gif]

Our commitment to Technology for 
Good 
and Diversity and 
Inclusion contributes 
to positive change.
Follow us on: Facebook 
LinkedIn 
Twitter

This communication is confidential. Our email terms: 
www.ericsson.com/en/legal/privacy/email-disclaimer

Re: [codec] DigestUtils / NoClassDefFoundError

[Bruno P. Kinoshita]

 Hi,
Since you mentioned it compiles fine, I guess this:

>Might this be due to a missing dependency ?
+1 you might have to confirm you have commons-codec available at runtime.
CheersBruno


On Saturday, 6 November 2021, 12:23:28 am NZDT, Vandewalle, Francois (GE 
Power)  wrote:  
 
 Hi !

I am developing with Java 11 (OpenJDK) and have the following runtime problem 
when calling DBUtils.md5Hex()
Exception in thread "Thread-0" java.lang.NoClassDefFoundError: 
org/apache/commons/codec/digest/DigestUtils

The purpose of my code is very classical: a history-aware save function, which 
only overwrites a file when the content to save differs from the content in the 
existing file (see below).

Surprisingly, compilation works fine.

Does apache commons codec support Java 11 ?
Am I doing something wrong ?
Might this be due to a missing dependency ?


Best regards,

François Vandewalle


    public boolean save(String target_file_name){
        try {
            // Check whether the file changed by comparing MD5 hashes
            String md5_existing_file = "";
            try (InputStream in = new FileInputStream(target_file_name)) {
                md5_existing_file = DigestUtils.md5Hex(in);
            }
            String md5_new_content;
            md5_new_content = DigestUtils.md5Hex(file_content);

            if (!md5_new_content.equals(md5_existing_file)){
                try (BufferedWriter out = new BufferedWriter(new 
FileWriter(target_file_name, false))) {
                    try {
                        out.write(file_content);
                    }
                    catch (IOException ioEx) {
                    }
                }
            }
        }
        catch (IOException ioEx){

        }

        return true;
    }

François Vandewalle
Systems Engineer / Development & Automation
GE Power
Power Conversion
T +49 30 7622 3818
F +49 30 7622 3737
francois.vandewa...@ge.com
www.gepowerconversion.com

Culemeyerstraße 1 | 12277 Berlin, Germany

GE Energy Power Conversion GmbH
Geschäftsführung: Jörg Nuttelmann, Martin Fleischer; Aufsichtsratsvorsitz: 
Wolfgang Dierker
Registergericht: Berlin-Charlottenburg; HRB 121288; USt-IdNr.: DE 269448104

Diese E-Mail und alle Daten, die darin übertragen werden, sind vertraulich und 
allein für den Adressaten
bestimmt. Falls Sie diese E-Mail irrtümlich erhalten, bitten wir um Mitteilung 
und darum, sie vollständig
von Ihrem Computer zu löschen.

This e-mail and any files transmitted with it are confidential and solely for 
the use of the individual or
entity to whom they are intended. If you have received this e-mail in error 
please notify the sender either
by telephone or by e-mail and delete the material from any computer.


  

Re: [codec] DigestUtils / NoClassDefFoundError

[Gary Gregory]

It looks like you do not have Commons Codec on the classpath at runtime.

Gary

On Fri, Nov 5, 2021, 07:23 Vandewalle, Francois (GE Power) <
francois.vandewa...@ge.com> wrote:

> Hi !
>
> I am developing with Java 11 (OpenJDK) and have the following runtime
> problem when calling DBUtils.md5Hex()
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError:
> org/apache/commons/codec/digest/DigestUtils
>
> The purpose of my code is very classical: a history-aware save function,
> which only overwrites a file when the content to save differs from the
> content in the existing file (see below).
>
> Surprisingly, compilation works fine.
>
> Does apache commons codec support Java 11 ?
> Am I doing something wrong ?
> Might this be due to a missing dependency ?
>
>
> Best regards,
>
> François Vandewalle
>
>
> public boolean save(String target_file_name){
> try {
> // Check whether the file changed by comparing MD5 hashes
> String md5_existing_file = "";
> try (InputStream in = new FileInputStream(target_file_name)) {
> md5_existing_file = DigestUtils.md5Hex(in);
> }
> String md5_new_content;
> md5_new_content = DigestUtils.md5Hex(file_content);
>
> if (!md5_new_content.equals(md5_existing_file)){
> try (BufferedWriter out = new BufferedWriter(new
> FileWriter(target_file_name, false))) {
> try {
> out.write(file_content);
> }
> catch (IOException ioEx) {
> }
> }
> }
> }
> catch (IOException ioEx){
>
> }
>
> return true;
> }
>
> François Vandewalle
> Systems Engineer / Development & Automation
> GE Power
> Power Conversion
> T +49 30 7622 3818
> F +49 30 7622 3737
> francois.vandewa...@ge.com
> www.gepowerconversion.com
>
> Culemeyerstraße 1 | 12277 Berlin, Germany
>
> GE Energy Power Conversion GmbH
> Geschäftsführung: Jörg Nuttelmann, Martin Fleischer; Aufsichtsratsvorsitz:
> Wolfgang Dierker
> Registergericht: Berlin-Charlottenburg; HRB 121288; USt-IdNr.: DE 269448104
>
> Diese E-Mail und alle Daten, die darin übertragen werden, sind vertraulich
> und allein für den Adressaten
> bestimmt. Falls Sie diese E-Mail irrtümlich erhalten, bitten wir um
> Mitteilung und darum, sie vollständig
> von Ihrem Computer zu löschen.
>
> This e-mail and any files transmitted with it are confidential and solely
> for the use of the individual or
> entity to whom they are intended. If you have received this e-mail in
> error please notify the sender either
> by telephone or by e-mail and delete the material from any computer.
>
>
>

Re: [codec] Problem with the BinaryCodec class

[Alex Herbert]

Hi,

This is functioning as expected. The input array of bytes is interpreted in
little-endian order. The first byte in the input array is the smallest part
of the output binary string interpreted as a binary number. So if you pass
two bytes the output string will start with the second byte and end with
the first byte when reading left to right.

You can see how this works by looking at the test for the method here:

https://gitbox.apache.org/repos/asf?p=commons-codec.git;a=blob;f=src/test/java/org/apache/commons/codec/binary/BinaryCodecTest.java;h=2e3e6380bcc08d913f514deaebbdfa3a325600ed;hb=HEAD#l296

As you set more bits in each byte (filling from the lowest bit first) the
output string fills up from the right.

The output order is a format for data transfer. The key point is that the
output string will be correctly converted back to the original bytes using
the complementary BinaryCodec.fromAscii method.

Regards,

Alex


On Thu, 4 Mar 2021 at 14:20, t_liang  wrote:

> System.out.println(BinaryCodec.toAsciiString(new byte[] { 'a' })); //
> output 0111 System.out.println(BinaryCodec.toAsciiString(new byte[] {
> 'b' })); // output 01100010
> System.out.println(BinaryCodec.toAsciiString(new byte[] { 'a', 'b' })); //
> output 011000100111(ba), why not 011101100010(ab)?

Re: [codec] Questions for Apache Commons Codec information disclosure

[Gary Gregory]

It might be https://issues.apache.org/jira/browse/CODEC-134

Gary

On Tue, Sep 22, 2020 at 11:19 AM De Zhi Mou  wrote:

> Hi,
>
> Our product received this vulnerability, apache-commons-codec-info-disc
> (177835).
> In the advisory references, there is a link to
> https://www.whitesourcesoftware.com/vulnerability-database/WS-2019-0379
> which says Apache commons-codec before version “commons-codec-1.13-RC1” is
> vulnerable to information disclosure due to Improper Input validation.
>
> We want to know what kind of improper input validation would cause the
> vulnerability. I look through all the references but cannot get that
> information. Are there any examples or testing codes?
> We do not directly use codec in our product, but we use HttpClient, which
> requires codec. Are we still vulnerable or not in this case?
>
> Really appreciate for your help. Thanks.
>
>
> Regards,
> Paul
> ---
> Paul ( DeZhi Mou, 牟德志)
> ClearQuest/Traxiem Software Engineer
> HCL Software
>
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>

Re: [codec] Hex encode

[sebb]

On Sat, 28 Sep 2019 at 06:21, Or Mark  wrote:
>
> Hello,
>
> About commons-codec Hex encoding methods,
> I suggest adding to Hex static encode method which returns byte[]
> It will be consistent with other encoding classes that have such method as
> Base64(same package) and MessageDigest.

Base64 has a static method, but this actually calls a method on a
cached instance using UTF-8.
The use of UTF-8 is noted in the Javadoc.

> I don't see a real reason to use instance method in this case.

It uses the instance Charset, as noted in the Javadoc.

> I would like to contribute this method to library.

What is the use case for this?

> First asked in
> https://stackoverflow.com/questions/58128819/apache-common-codec-why-hex-encode-isnt-static/58129148#58129148

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

Re: [codec] Base32 decode is not case-insensitive?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Can I get a review (and hopefully a commit) on this issue?

https://issues.apache.org/jira/browse/CODEC-234

I'd really like to have these features available directly in the
library instead of having to massage input before handing it off to
commons-codec.

Thanks,
- -chris

On 5/1/17 3:21 PM, Christopher Schultz wrote:
> Paulo,
> 
> On 5/1/17 1:35 PM, Paulo Roberto Massa Cereda wrote:
>> Apologies, I quoted the wrong bit!
> 
>> --8< When decoding, upper and lower case 
>> letters are accepted, and i and l will be treated as 1 and o
>> will be treated as 0. When encoding, only upper case letters are
>> used. --8<
> 
> So... none of the above are true in commons-codec. Was it the
> intent to follow Douglas Crawfords recommendations? If so, it's
> quite incompatible with RFC 4648.
> 
> I think I'll file a JIRA issue for this and attach a patch.[1]
> 
> Thanks, -chris
> 
> [1] https://issues.apache.org/jira/browse/CODEC-234
> 
>> Em 01-05-2017 14:31, Paulo Roberto Massa Cereda escreveu:
>>> 'ello!
>>> 
>>> I suspect it has something to do with Douglas Crockford's
>>> base32 [1]:
>>> 
>>> -8<--- The encoding scheme is required 
>>> to
>>> 
>>> * Be human readable and machine readable. * Be compact. Humans 
>>> have difficulty in manipulating long strings of arbitrary 
>>> symbols. * Be error resistant. Entering the symbols must not 
>>> require keyboarding gymnastics. * Be pronounceable. Humans
>>> should be able to accurately transmit the symbols to other
>>> humans using a telephone. -8<---
>>> 
>>> [1]: http://www.crockford.com/wrmg/base32.html
>>> 
>>> Cheerio!
>>> 
>>> Paulo
>>> 
>>> Em 01-05-2017 14:00, Christopher Schultz escreveu:
>> All,
> 
>> I spent a few hours trying to figure out what I had done wrong 
>> when trying to base32-decode a 32-character string and was
>> getting a 5-byte array back (instead of a 20-byte array, as
>> expected).
> 
>> I finally determined that Base32.decode doesn't work properly
>> with lower-case input strings.
> 
>> Is there a particular reason that these don't work? Here's an 
>> example:
> 
>> import org.apache.commons.codec.binary.Base32; import 
>> org.apache.commons.codec.binary.Hex;
> 
>> public class Test { public static void main(String[] args)
>> throws Exception { byte[] bytes = new 
>> Base32().decode("MI5AC42YG3U2CJXBF67ZLYAT5ZUJFGL4");
> 
>> System.out.println("bytes.length=" + bytes.length); 
>> System.out.println("hex=" + Hex.encodeHexString(bytes));
> 
>> bytes = new Base32().decode("mi5ac42yg3u2cjxbf67zlyat5zujfgl4");
> 
>> System.out.println("bytes.length=" + bytes.length); 
>> System.out.println("hex=" + Hex.encodeHexString(bytes)); } }
> 
>> Produces this output:
> 
>> bytes.length=20 hex=623a01735836e9a126e12fbf95e013ee6892997c 
>> bytes.length=5 hex=ef35bd7bfd
> 
>> It looks like Base32.decode is ignoring all of the characters it
>>  doesn't see as being "in" its alphabet (all the lowercase
>> letters) and uses what is left over ("542326754" in the case
>> above). If I base32-decode "542326754" I get the 5-byte output
>> that the second case generates.
> 
>> While RFC4648 doesn't specifically say that input strings should 
>> be allowed to be case-insensitive, it does have this to say:
> 
>> " The Base 32 encoding is designed to represent arbitrary
>> sequences of octets in a form that needs to be case insensitive
>> but that need not be human readable. " [1]
> 
>> The mention of case-insensitivity leads me to believe that case 
>> should be ignored for decoding. The javadoc for the Base32 class 
>> makes no mention of the requirement for input strings to be in 
>> UPPER CASE, either .
> 
>> Would there be any appetite for extending the Base32 decoder to
>> be case-insensitive?
> 
>> I have a small patch and test case that look like they'll do the 
>> trick.
> 
>> Thanks, -chris
> 
>> [1] https://tools.ietf.org/html/rfc4648#section-6
 
 ---
- -
>
 
- -
 
 
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail:
 user-h...@commons.apache.org
 
> 
>> -
>
>> 
> 
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
> 
> 
> 
> -
>
> 
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZw8nlAAoJEBzwKT+lPKRYW44QAJ3fGGJFGu9gwANrUAzclAmZ
7Krtn6fSBESnzfmn9AsY1j7Mc5gpQxchjbhD95/Mqk1qDhq+KlpdDEPATcgBwOkf

Re: [codec] Base32 decode is not case-insensitive?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paulo,

On 5/1/17 1:35 PM, Paulo Roberto Massa Cereda wrote:
> Apologies, I quoted the wrong bit!
> 
> --8< When decoding, upper and lower case
> letters are accepted, and i and l will be treated as 1 and o will
> be treated as 0. When encoding, only upper case letters are used. 
> --8<

So... none of the above are true in commons-codec. Was it the intent to
follow Douglas Crawfords recommendations? If so, it's quite
incompatible with RFC 4648.

I think I'll file a JIRA issue for this and attach a patch.[1]

Thanks,
- -chris

[1] https://issues.apache.org/jira/browse/CODEC-234

> Em 01-05-2017 14:31, Paulo Roberto Massa Cereda escreveu:
>> 'ello!
>> 
>> I suspect it has something to do with Douglas Crockford's base32
>> [1]:
>> 
>> -8<--- The encoding scheme is required
>> to
>> 
>> * Be human readable and machine readable. * Be compact. Humans
>> have difficulty in manipulating long strings of arbitrary
>> symbols. * Be error resistant. Entering the symbols must not
>> require keyboarding gymnastics. * Be pronounceable. Humans should
>> be able to accurately transmit the symbols to other humans using
>> a telephone. -8<---
>> 
>> [1]: http://www.crockford.com/wrmg/base32.html
>> 
>> Cheerio!
>> 
>> Paulo
>> 
>> Em 01-05-2017 14:00, Christopher Schultz escreveu:
> All,
> 
> I spent a few hours trying to figure out what I had done wrong
> when trying to base32-decode a 32-character string and was getting
> a 5-byte array back (instead of a 20-byte array, as expected).
> 
> I finally determined that Base32.decode doesn't work properly with 
> lower-case input strings.
> 
> Is there a particular reason that these don't work? Here's an
> example:
> 
> import org.apache.commons.codec.binary.Base32; import
> org.apache.commons.codec.binary.Hex;
> 
> public class Test { public static void main(String[] args) throws
> Exception { byte[] bytes = new 
> Base32().decode("MI5AC42YG3U2CJXBF67ZLYAT5ZUJFGL4");
> 
> System.out.println("bytes.length=" + bytes.length); 
> System.out.println("hex=" + Hex.encodeHexString(bytes));
> 
> bytes = new Base32().decode("mi5ac42yg3u2cjxbf67zlyat5zujfgl4");
> 
> System.out.println("bytes.length=" + bytes.length); 
> System.out.println("hex=" + Hex.encodeHexString(bytes)); } }
> 
> Produces this output:
> 
> bytes.length=20 hex=623a01735836e9a126e12fbf95e013ee6892997c 
> bytes.length=5 hex=ef35bd7bfd
> 
> It looks like Base32.decode is ignoring all of the characters it 
> doesn't see as being "in" its alphabet (all the lowercase letters)
> and uses what is left over ("542326754" in the case above). If I 
> base32-decode "542326754" I get the 5-byte output that the second
> case generates.
> 
> While RFC4648 doesn't specifically say that input strings should
> be allowed to be case-insensitive, it does have this to say:
> 
> " The Base 32 encoding is designed to represent arbitrary sequences
> of octets in a form that needs to be case insensitive but that need
> not be human readable. " [1]
> 
> The mention of case-insensitivity leads me to believe that case
> should be ignored for decoding. The javadoc for the Base32 class
> makes no mention of the requirement for input strings to be in
> UPPER CASE, either .
> 
> Would there be any appetite for extending the Base32 decoder to be 
> case-insensitive?
> 
> I have a small patch and test case that look like they'll do the
> trick.
> 
> Thanks, -chris
> 
> [1] https://tools.ietf.org/html/rfc4648#section-6
>>> 
>>> 
- -
>>>
>>> 
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: user-h...@commons.apache.org
>>> 
> 
> -
>
> 
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZB4qmAAoJEBzwKT+lPKRYKvgP/1x1Sjn9IxurD+1D++QssN+0
Mw93Uw8v5ZCkSUYxjcLs5V89mR0acAH0ixcOvmYJSmu5HGR5aoVmc1L+kFnryk19
TSpSUvw8lIlVgx6Mkvfksjw5kNZ/os304yYAm0dKfkr3d50tVJHzSRSz8RT9y+PR
ttzsIydGGQ+ukK+1xqIat0IyINI2WwQVc8wXP83Ct+ASdsf7zjMCMT6KVrGWq+dm
1dzhFIOD4Wj8F9tF78IfjTgnG6KgklFfWOXxWV05CvfTgNw8DLRIxUs1EI9ShvDc
+FhpTPoHjPq+LBEAEepK/2WupRwK7ehmsnmTerfyW1UhbeEzvE0vOkqow3OFr7hC
vvo9Y17z0DCv/cIk2fPCrAJUOqEY6f+cTCFZuV5HOVN2n5OvZWSTujrECUl/0QAF
Ct+FiusdfjTB6Rz2MAndSSe/Fb9OsE+7wIjtYNFldKt51VWSGZpAspwnHFUNF1Ph
fQkTSHKm0FaGUOOUq2YzSYk4YzzJYrF8W51jD5FD+/HmH1mbaISrtWTQ4VYxHDmV
T0/IDwQL0D1sCdZdjvR/wzRV8T+Ogkd/oGHIFh/WXvtgTrgxO0BxS+WND9aEn4gm
omErr45W67oa+Xt3kJjZIMgHppuJSBhajI19K7MA6h2kSS0gho4gpVf4b4MOx1WB
P5TPMuMe/h3GjVAW8/x/
=yEbV
-END PGP SIGNATURE-

-
To 

Re: [codec] Base32 decode is not case-insensitive?

[Paulo Roberto Massa Cereda]

Apologies, I quoted the wrong bit!

--8<
When decoding, upper and lower case letters are accepted, and i and l 
will be treated as 1 and o will be treated as 0. When encoding, only 
upper case letters are used.

--8<

Best,

Paulo

Em 01-05-2017 14:31, Paulo Roberto Massa Cereda escreveu:

'ello!

I suspect it has something to do with Douglas Crockford's base32 [1]:

-8<---
The encoding scheme is required to

* Be human readable and machine readable.
* Be compact. Humans have difficulty in manipulating long strings of 
arbitrary symbols.
* Be error resistant. Entering the symbols must not require keyboarding 
gymnastics.
* Be pronounceable. Humans should be able to accurately transmit the 
symbols to other humans using a telephone.

-8<---

[1]: http://www.crockford.com/wrmg/base32.html

Cheerio!

Paulo

Em 01-05-2017 14:00, Christopher Schultz escreveu:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I spent a few hours trying to figure out what I had done wrong when
trying to base32-decode a 32-character string and was getting a 5-byte
array back (instead of a 20-byte array, as expected).

I finally determined that Base32.decode doesn't work properly with
lower-case input strings.

Is there a particular reason that these don't work? Here's an example:

import org.apache.commons.codec.binary.Base32;
import org.apache.commons.codec.binary.Hex;

public class Test {
 public static void main(String[] args) throws Exception {
 byte[] bytes = new
Base32().decode("MI5AC42YG3U2CJXBF67ZLYAT5ZUJFGL4");

 System.out.println("bytes.length=" + bytes.length);
 System.out.println("hex=" + Hex.encodeHexString(bytes));

 bytes = new Base32().decode("mi5ac42yg3u2cjxbf67zlyat5zujfgl4");

 System.out.println("bytes.length=" + bytes.length);
 System.out.println("hex=" + Hex.encodeHexString(bytes));
 }
}

Produces this output:

bytes.length=20
hex=623a01735836e9a126e12fbf95e013ee6892997c
bytes.length=5
hex=ef35bd7bfd

It looks like Base32.decode is ignoring all of the characters it
doesn't see as being "in" its alphabet (all the lowercase letters) and
uses what is left over ("542326754" in the case above). If I
base32-decode "542326754" I get the 5-byte output that the second case
generates.

While RFC4648 doesn't specifically say that input strings should be
allowed to be case-insensitive, it does have this to say:

"
The Base 32 encoding is designed to represent arbitrary sequences of
octets in a form that needs to be case insensitive but that need not
be human readable.
" [1]

The mention of case-insensitivity leads me to believe that case should
be ignored for decoding. The javadoc for the Base32 class makes no
mention of the requirement for input strings to be in UPPER CASE, either
.

Would there be any appetite for extending the Base32 decoder to be
case-insensitive?

I have a small patch and test case that look like they'll do the trick.

Thanks,
- -chris

[1] https://tools.ietf.org/html/rfc4648#section-6
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZB2mSAAoJEBzwKT+lPKRYDcUQAKuumWhCQpNRwblxm37jhQ8N
EqYtYneDtslKx5EQwq2Szx1tDvn56JsX28Kuc1EfcaSyiVueu+IKV076EG7dueWb
SleXlAz02/XYr97ks83KsCl6gUDEjoEMG/+U7hcrC06yCOGtPQtXEBT9N5+CF7Gg
YlIt6mZ5ZbGuFVjvOc/FiORv7u0k9X8h0PmF5luYSsBgrgmoSAIHUy9VmwZIsD13
NwBTtGarGxJhS65YNfmxIpln5Zv95FojeMKbArhvd9P7cmRJs8ydcE/rydYVa373
R9yy5aYtFOO1mOBZp4YpDvn9oUTmcjlK9bsxOhNld2dNLW+ANE44VYtJb6Dr71ym
x37Ez8eJX9kJSe9kB5EWnJh5/epRX7m7H6PZeJNx6riGfKxmH6iPwcJ9ncyk076f
o09USE43lT1VUFcgZ6w5XeDAHEkYSQMNz7jGpJ7egpPtZ/BHsijxlTnygD2AjT/3
qY4hgYRYz2hlVwrw84/1TZq8zI7Anzfet9XROdMfhJs2popFVbxLPHz5aV75Pjhm
hlsggHiSKb2pbTNzjWEogWrKbX2MJ+c/pcKGwSINWlnoAO+7y5kVwaayFrmD2FLt
GXKDO/DnsjY1NRDeVcN/MH1CHGwdEr+KhIkzc6rhvK/Eh8UQs2/wrGZRFvqEfQrX
iG3y4rRSX+sPaG6HW+9r
=JIze
-END PGP SIGNATURE-

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



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

Re: [codec] Base32 decode is not case-insensitive?

[Paulo Roberto Massa Cereda]

'ello!

I suspect it has something to do with Douglas Crockford's base32 [1]:

-8<---
The encoding scheme is required to

* Be human readable and machine readable.
* Be compact. Humans have difficulty in manipulating long strings of 
arbitrary symbols.
* Be error resistant. Entering the symbols must not require keyboarding 
gymnastics.
* Be pronounceable. Humans should be able to accurately transmit the 
symbols to other humans using a telephone.

-8<---

[1]: http://www.crockford.com/wrmg/base32.html

Cheerio!

Paulo

Em 01-05-2017 14:00, Christopher Schultz escreveu:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I spent a few hours trying to figure out what I had done wrong when
trying to base32-decode a 32-character string and was getting a 5-byte
array back (instead of a 20-byte array, as expected).

I finally determined that Base32.decode doesn't work properly with
lower-case input strings.

Is there a particular reason that these don't work? Here's an example:

import org.apache.commons.codec.binary.Base32;
import org.apache.commons.codec.binary.Hex;

public class Test {
 public static void main(String[] args) throws Exception {
 byte[] bytes = new
Base32().decode("MI5AC42YG3U2CJXBF67ZLYAT5ZUJFGL4");

 System.out.println("bytes.length=" + bytes.length);
 System.out.println("hex=" + Hex.encodeHexString(bytes));

 bytes = new Base32().decode("mi5ac42yg3u2cjxbf67zlyat5zujfgl4");

 System.out.println("bytes.length=" + bytes.length);
 System.out.println("hex=" + Hex.encodeHexString(bytes));
 }
}

Produces this output:

bytes.length=20
hex=623a01735836e9a126e12fbf95e013ee6892997c
bytes.length=5
hex=ef35bd7bfd

It looks like Base32.decode is ignoring all of the characters it
doesn't see as being "in" its alphabet (all the lowercase letters) and
uses what is left over ("542326754" in the case above). If I
base32-decode "542326754" I get the 5-byte output that the second case
generates.

While RFC4648 doesn't specifically say that input strings should be
allowed to be case-insensitive, it does have this to say:

"
The Base 32 encoding is designed to represent arbitrary sequences of
octets in a form that needs to be case insensitive but that need not
be human readable.
" [1]

The mention of case-insensitivity leads me to believe that case should
be ignored for decoding. The javadoc for the Base32 class makes no
mention of the requirement for input strings to be in UPPER CASE, either
.

Would there be any appetite for extending the Base32 decoder to be
case-insensitive?

I have a small patch and test case that look like they'll do the trick.

Thanks,
- -chris

[1] https://tools.ietf.org/html/rfc4648#section-6
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZB2mSAAoJEBzwKT+lPKRYDcUQAKuumWhCQpNRwblxm37jhQ8N
EqYtYneDtslKx5EQwq2Szx1tDvn56JsX28Kuc1EfcaSyiVueu+IKV076EG7dueWb
SleXlAz02/XYr97ks83KsCl6gUDEjoEMG/+U7hcrC06yCOGtPQtXEBT9N5+CF7Gg
YlIt6mZ5ZbGuFVjvOc/FiORv7u0k9X8h0PmF5luYSsBgrgmoSAIHUy9VmwZIsD13
NwBTtGarGxJhS65YNfmxIpln5Zv95FojeMKbArhvd9P7cmRJs8ydcE/rydYVa373
R9yy5aYtFOO1mOBZp4YpDvn9oUTmcjlK9bsxOhNld2dNLW+ANE44VYtJb6Dr71ym
x37Ez8eJX9kJSe9kB5EWnJh5/epRX7m7H6PZeJNx6riGfKxmH6iPwcJ9ncyk076f
o09USE43lT1VUFcgZ6w5XeDAHEkYSQMNz7jGpJ7egpPtZ/BHsijxlTnygD2AjT/3
qY4hgYRYz2hlVwrw84/1TZq8zI7Anzfet9XROdMfhJs2popFVbxLPHz5aV75Pjhm
hlsggHiSKb2pbTNzjWEogWrKbX2MJ+c/pcKGwSINWlnoAO+7y5kVwaayFrmD2FLt
GXKDO/DnsjY1NRDeVcN/MH1CHGwdEr+KhIkzc6rhvK/Eh8UQs2/wrGZRFvqEfQrX
iG3y4rRSX+sPaG6HW+9r
=JIze
-END PGP SIGNATURE-

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



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

Re: [codec] Codec 1.10 requires Java 6 or Java 7?

[Gary Gregory]

Codec 1.10 requires Java 6.

Java 6 is EOL though. So one should really code to at least Java 7 if
possible, hence the redirect to Java 7's StandardChars
ets.

Gary

On Mon, Nov 17, 2014 at 6:45 PM, Thib Guicherd-Callin t...@cs.stanford.edu
wrote:


 The 'Releases' paragraph of the front page:

 http://commons.apache.org/proper/commons-codec/index.html

 says Codec 1.10 (mirrors) requires Java 1.6. But the release notes for
 1.10:

 http://commons.apache.org/proper/commons-codec/changes-report.html#a1.10

 list JIRA issue CODEC-178:

 https://issues.apache.org/jira/browse/CODEC-178

 as a bug fix, and the title Deprecate Charsets Charset constants in favor
 of Java 7's java.nio.charset.StandardCharsets could be construed to mean
 Java 7 is required. So, is Java 7 required, or does the 1.10 fix for
 CODEC-178 work with Java 6?

 Thib






 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-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

Re: [codec] - change transitive dependency from commons-codec-1.3 to 1.6 or 1.9

[Gary Gregory]

In theory, no, but you should read the release notes.

Gary

On Thu, Oct 16, 2014 at 7:17 AM, GIPA mbH Di Ly d...@gipa.de wrote:

 Our software has a transitive dependency to commons-codec-1.3. Is there
 any problem when I change the commons-codec-1.3 to 1.6 or 1.9?



 Thanks.

 Ly




-- 
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

Re: [codec] - change transitive dependency from commons-codec-1.3 to 1.6 or 1.9

[Matt Benson]

May I also suggest you read [1].

[1] http://semver.org/

Matt
On Oct 16, 2014 8:10 AM, Gary Gregory garydgreg...@gmail.com wrote:

 In theory, no, but you should read the release notes.

 Gary

 On Thu, Oct 16, 2014 at 7:17 AM, GIPA mbH Di Ly d...@gipa.de wrote:

  Our software has a transitive dependency to commons-codec-1.3. Is there
  any problem when I change the commons-codec-1.3 to 1.6 or 1.9?
 
 
 
  Thanks.
 
  Ly
 



 --
 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

Re: [codec] problem with Base64OutputStream

[Thad Humphries]

On Sun, Feb 17, 2013 at 4:56 AM, Thomas Neidhart
thomas.neidh...@gmail.comwrote:

 On 02/17/2013 12:13 AM, Thad Humphries wrote:
  I am using Commons Codec v1.7 to Base64 encode a TIFF file for writing to
  an XML file as CDATA. Simple:
 
  File file = new File(fileName);
  FileInputStream fis = new FileInputStream(file);
  ByteArrayOutputStream baos = new ByteArrayOutputStream();
  Base64OutputStream b64os = new Base64OutputStream(baos);
  int bufSize = 8 * 1024;
  byte [] buffer = new byte[bufSize];
  int count;
  while ((count = fis.read(buffer, 0, bufSize)) != -1)
b64os.write(buffer, 0, count);
  fis.close();
  baos.flush();
  b64os.close();
  baos.close();
  xtw.writeCData(new String(baos.toByteArray()));
 
  However I'm concerned that a future version Commons Codec of might not
  default to chunked output. So I'd like to swap
 
  Base64OutputStream b64os = new Base64OutputStream(baos);
 
  for
 
  byte [] eol = {0xD, 0xA};
  Base64OutputStream b64os = new Base64OutputStream(baos, true, 76,
  eol);
 
  However when I do this, the program crashes out on creating new
  Base64OutputStream(...). If fact, it skips right past a catch on
 Exception
  and goes directly to finally (honest--my logger shows nothing and I've
  watched this dozens of times in Eclipse's deugger).
 
  Am I doing something wrong?

 Hi Thad,

 I just tried your example and this works pretty fine for me. Could you
 please post the exception you are getting?

 Thomas


Hi Thomas,

Thanks for the response. The call does not catch as an Exception, but just
now I found that it catches as a Throwable. My log4j log is below. Line
1703 is where I instantiate Base64OutputStream:

Base64OutputStream b64os = new Base64OutputStream(baos, true, 76, eol);

From the log.

java.lang.VerifyError: (class:
org/apache/commons/codec/binary/Base64OutputStream, method: init
signature: (Ljava/io/OutputStream;ZI[B)V) Incompatible argument to function
at
com.optix.cold.server.ColdServicesImpl.makeColdFormFile(ColdServicesImpl.java:1703)
at
com.optix.cold.server.ColdServicesImpl.saveColdForm(ColdServicesImpl.java:1339)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
at
com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1097)
at
com.optix.cold.server.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:52)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1088)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:729)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at
org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:49)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)



-- 
Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be --Christopher
Marlowe, *Doctor Faustus* (v, 121-24)

Re: [codec] Java 1.3 compliant base64 encoder / decoder

[Julius Davies]

I think commons-codec-1.3.jar (coincidentally) should work with Java 1.3.

You can find it here:

http://archive.apache.org/dist/commons/codec/binaries/

Unfortunately commons-codec-1.3.jar is unable to do streaming Base64,
but as long as you can fit everything in memory, it works great with
byte[] arrays.


Or you can try to back-port commons-codec-1.6 to work with Java 1.3.
If you go that route I think you just need to pull out the following
classes.  There are probably some modifications you'll need to make it
compile under Java 1.3, but it might be possible.

Base64InputStream.java
Base64.java
Base64OutputStream.java
BaseNCodecInputStream.java
BaseNCodec.java
BaseNCodecOutputStream.java


You would also need to remove the implements declarations
(BinaryEncoder, Encoder, BinaryDecoder, Encoder), and figure what to
do with the EncodingException and DecodingException --- either pull
those out and compile them, too, or replace with RuntimeException, or
create your own.

Good luck!

yours,

Julius



On Thu, Aug 23, 2012 at 3:44 PM, Hendré Louw hen...@lot24media.co.za wrote:
 Hello

 I am working on a BlackBerry Java 1.3 compliant mobile application and want
 to embed binary image data in a JSON structure. What version of the
 commons-codec source can I use to adapt or just compile a Java 1.3
 compliant base64
 encoder/decoder?

 Hendré



-- 
yours,

Julius Davies
604-222-3310 (Home)

$ sudo apt-get install cowsay
$ echo Moo. | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/

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

RE: [codec] Java 1.3 compliant base64 encoder / decoder

[Martin Gainty]

Im not sure what specific restrictions implementing a 1.3 JVM will impose but...

You can manipulate Base64 Images via encode and decode as byte[]
http://javadoc.google-api-java-client.googlecode.com/hg/1.3.1-alpha/

does this help?
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.


 Date: Thu, 23 Aug 2012 16:30:21 -0400
 Subject: Re: [codec] Java 1.3 compliant base64 encoder / decoder
 From: juliusdav...@gmail.com
 To: user@commons.apache.org
 
 I think commons-codec-1.3.jar (coincidentally) should work with Java 1.3.
 
 You can find it here:
 
 http://archive.apache.org/dist/commons/codec/binaries/
 
 Unfortunately commons-codec-1.3.jar is unable to do streaming Base64,
 but as long as you can fit everything in memory, it works great with
 byte[] arrays.
 
 
 Or you can try to back-port commons-codec-1.6 to work with Java 1.3.
 If you go that route I think you just need to pull out the following
 classes.  There are probably some modifications you'll need to make it
 compile under Java 1.3, but it might be possible.
 
 Base64InputStream.java
 Base64.java
 Base64OutputStream.java
 BaseNCodecInputStream.java
 BaseNCodec.java
 BaseNCodecOutputStream.java
 
 
 You would also need to remove the implements declarations
 (BinaryEncoder, Encoder, BinaryDecoder, Encoder), and figure what to
 do with the EncodingException and DecodingException --- either pull
 those out and compile them, too, or replace with RuntimeException, or
 create your own.
 
 Good luck!
 
 yours,
 
 Julius
 
 
 
 On Thu, Aug 23, 2012 at 3:44 PM, Hendré Louw hen...@lot24media.co.za wrote:
  Hello
 
  I am working on a BlackBerry Java 1.3 compliant mobile application and want
  to embed binary image data in a JSON structure. What version of the
  commons-codec source can I use to adapt or just compile a Java 1.3
  compliant base64
  encoder/decoder?
 
  Hendré
 
 
 
 -- 
 yours,
 
 Julius Davies
 604-222-3310 (Home)
 
 $ sudo apt-get install cowsay
 $ echo Moo. | cowsay | cowsay -n | cowsay -n
 http://juliusdavies.ca/cowsay/
 
 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org
 
  

Re: [codec] Java 1.3 compliant base64 encoder / decoder

[Hendré Louw]

Thank you Martin and Julius both your response and on the money!

On 23 August 2012 22:55, Martin Gainty mgai...@hotmail.com wrote:


 Im not sure what specific restrictions implementing a 1.3 JVM will impose
 but...

 You can manipulate Base64 Images via encode and decode as byte[]
 http://javadoc.google-api-java-client.googlecode.com/hg/1.3.1-alpha/

 does this help?
 Martin
 __
 Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

 Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
 Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
 Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
 dient lediglich dem Austausch von Informationen und entfaltet keine
 rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
 E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
 Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
 destinataire prévu, nous te demandons avec bonté que pour satisfaire
 informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
 de ceci est interdite. Ce message sert à l'information seulement et n'aura
 pas n'importe quel effet légalement obligatoire. Étant donné que les email
 peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
 aucune responsabilité pour le contenu fourni.


  Date: Thu, 23 Aug 2012 16:30:21 -0400
  Subject: Re: [codec] Java 1.3 compliant base64 encoder / decoder
  From: juliusdav...@gmail.com
  To: user@commons.apache.org
 
  I think commons-codec-1.3.jar (coincidentally) should work with Java 1.3.
 
  You can find it here:
 
  http://archive.apache.org/dist/commons/codec/binaries/
 
  Unfortunately commons-codec-1.3.jar is unable to do streaming Base64,
  but as long as you can fit everything in memory, it works great with
  byte[] arrays.
 
 
  Or you can try to back-port commons-codec-1.6 to work with Java 1.3.
  If you go that route I think you just need to pull out the following
  classes.  There are probably some modifications you'll need to make it
  compile under Java 1.3, but it might be possible.
 
  Base64InputStream.java
  Base64.java
  Base64OutputStream.java
  BaseNCodecInputStream.java
  BaseNCodec.java
  BaseNCodecOutputStream.java
 
 
  You would also need to remove the implements declarations
  (BinaryEncoder, Encoder, BinaryDecoder, Encoder), and figure what to
  do with the EncodingException and DecodingException --- either pull
  those out and compile them, too, or replace with RuntimeException, or
  create your own.
 
  Good luck!
 
  yours,
 
  Julius
 
 
 
  On Thu, Aug 23, 2012 at 3:44 PM, Hendré Louw hen...@lot24media.co.za
 wrote:
   Hello
  
   I am working on a BlackBerry Java 1.3 compliant mobile application and
 want
   to embed binary image data in a JSON structure. What version of the
   commons-codec source can I use to adapt or just compile a Java 1.3
   compliant base64
   encoder/decoder?
  
   Hendré
 
 
 
  --
  yours,
 
  Julius Davies
  604-222-3310 (Home)
 
  $ sudo apt-get install cowsay
  $ echo Moo. | cowsay | cowsay -n | cowsay -n
  http://juliusdavies.ca/cowsay/
 
  -
  To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
  For additional commands, e-mail: user-h...@commons.apache.org
 





-- 
Dear

Re: [codec] Base 64 problem

[Victor Sterpu]

I fixed this by using readFileToByteArray not readFileToString
byte[] zip_content=FileUtils.readFileToByteArray(new File(zip));


On 24.05.2011 19:11, Victor Sterpu wrote:
I'm trying to use org.apache.commons.codec.binary.Base64 to code in 
base64 a zip file but the result is not as expected.

The code used to encode is
String content = new 
String(Base64.encodeBase64(FileUtils.readFileToString(new 
File(FARMD_16611264_20110524_1102.xml.zip)).getBytes()));

The result is Base64 content 1.
The result that I must obtain is Base64 content 2 and this second 
string is generated using this online encoder 
http://www.opinionatedgeek.com/dotnet/tools/base64encode/.

I tryed all day to fix this but I can't figure it out.
Please give me an ideea about what is going on.
I attached the zip file that I try to encode.

Thank you.

Base64 content 1: 

Re: [codec] DigestUtils.md5Hex Exception inside Servlet

[Fahmi Hachicha]

Hello,

This was resolved by adding the jar file to the lib directory of the
deployment war file.
Thanks
Fahmi

2011/4/7 Henri Yandell flame...@gmail.com

 That's a pretty boring class Java-wise and it seems unlikely that your
 container is putting codec in the classpath on its own, so I suspect
 the problem is in how you're making the jar available within the
 servlet container.

 Hen

 On Thu, Apr 7, 2011 at 1:23 AM, Fahmi Hachicha fahmi.hachi...@gmail.com
 wrote:
  Hello,
 
  The DigestUtils.md5Hex method generate an exception when used inside a
  Servlet :
 
  java.lang.NoClassDefFoundError:
 org/apache/commons/codec/digest/DigestUtils
 
  The class DigestUtils works correctly when used in a test class with main
  method in the same project.
 
  The same error appears when it is used in a bean associated to a JSP page
  using MyFaces.
 
  Thanks
  Fahmi
 

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

Re: [codec] DigestUtils.md5Hex Exception inside Servlet

[Henri Yandell]

That's a pretty boring class Java-wise and it seems unlikely that your
container is putting codec in the classpath on its own, so I suspect
the problem is in how you're making the jar available within the
servlet container.

Hen

On Thu, Apr 7, 2011 at 1:23 AM, Fahmi Hachicha fahmi.hachi...@gmail.com wrote:
 Hello,

 The DigestUtils.md5Hex method generate an exception when used inside a
 Servlet :

 java.lang.NoClassDefFoundError: org/apache/commons/codec/digest/DigestUtils

 The class DigestUtils works correctly when used in a test class with main
 method in the same project.

 The same error appears when it is used in a bean associated to a JSP page
 using MyFaces.

 Thanks
 Fahmi


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

RE: [codec] Base64.decodeBase64(byte[]) behaves differently in commons.codec 1.3 vs 1.4

[Gary Gregory]

 -Original Message-
 From: Raphael Ackermann [mailto:raphael.ackerm...@gmail.com]
 Sent: Wednesday, May 19, 2010 04:57
 To: user@commons.apache.org
 Subject: [codec] Base64.decodeBase64(byte[]) behaves differently in
 commons.codec 1.3 vs 1.4
 
 Hi
 
 we switched this week from using commons codec 1.3 to 1.4 and
 discovered a bug in our code.
 
 we are using it like that:
 
 String enc = 1;
 Base64.decodeBase64(enc.getBytes())
 
 in v 1.3 this would return [0]
 in v 1.4 this returns []   which caused a problem in our code.
 
 Looking at the changes from 1.3 to 1.4 I didn't see one relating to
 such a behaviour change. Is this intentional? Was the old behaviour a
 bug in 1.3 and changing it in v 1.4 fixed it?
 
 Raphael

At a glance, this might be related to 
https://issues.apache.org/jira/browse/CODEC-91

The open CODEC issues are: 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310464status=1status=3status=4sorter/field=issuekeysorter/order=ASC

Gary

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


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

Re: [CODEC] Migrate issue from 1.3 to 1.4

[Julius Davies]

I bet you it's a similar bug to this:

http://code.google.com/p/oauth-signpost/issues/detail?id=18

3. The python-oauth library (the reference implementation for OAuth)
barfs because the signature is IYALjIZeGwFri8xtv4uIaDBO3Ow%3D%0D%0A
which decodes to 'IYALjIZeGwFri8xtv4uIaDBO3Ow=\r\n'.



Some code I wrote tonight highlights the problem:  the static
Base64.encodeBase64() vs. the instance (new Base64().encode()) methods
are behaving differently in this regard.  Since the unit-tests mostly
focus on the static methods, we missed this variation.


import org.apache.commons.codec.binary.*;

public class B64 {

  public static void main(String[] args) throws Exception {
Base64 b64 = new Base64();

String s1 =
aa;
String s2 = aa;
String s3 = a;

byte[] b1 = s1.getBytes(UTF-8);
byte[] b2 = s2.getBytes(UTF-8);
byte[] b3 = s3.getBytes(UTF-8);

byte[] result;
result = Base64.encodeBase64(b1);
System.out.println([ + new String(result, UTF-8) + ]);
result = b64.encode(b1);
System.out.println([ + new String(result, UTF-8) + ]);

result = Base64.encodeBase64(b2);
System.out.println([ + new String(result, UTF-8) + ]);
result = b64.encode(b2);
System.out.println([ + new String(result, UTF-8) + ]);

result = Base64.encodeBase64(b3);
System.out.println([ + new String(result, UTF-8) + ]);
result = b64.encode(b3);
System.out.println([ + new String(result, UTF-8) + ]);

  }
}


Here's my output:


$ java -cp commons-codec-1.3.jar:. B64
[YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
[YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
[YWFhYWFhYWFhYQ==]
[YWFhYWFhYWFhYQ==]
[YQ==]
[YQ==]

$ java -cp commons-codec-1.4.jar:. B64
[YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==]
[YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYQ==
]
[YWFhYWFhYWFhYQ==]
[YWFhYWFhYWFhYQ==
]
[YQ==]
[YQ==
]




yours,

Julius



On Mon, Oct 26, 2009 at 1:10 PM, Gary Gregory
ggreg...@seagullsoftware.com wrote:

 Can you please be more specific? Can you supply a test case?

 Thank you,
 Gary

  -Original Message-
  From: Murat Yücel [mailto:kodeperke...@gmail.com]
  Sent: Monday, October 26, 2009 13:09
  To: user
  Subject: [CODEC] Migrate issue from 1.3 to 1.4
 
  Hi All
 
  We are currently using commons-codec in our project. We have used this
  version for about one year.
  This means that we have a lot of users in our database with encrypted
  password. We have used the Base64
  class to encode the passwords.
  The problem is that after upgrading to 1.4 none of the users can
  login, so we have made a rollback.
 
  Is this a known issue? I havent find anything on your website.
 
  Regards
 
  /Murat
 
  -
  To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
  For additional commands, e-mail: user-h...@commons.apache.org


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




--
yours,

Julius Davies
250-592-2284 (Home)
250-893-4579 (Mobile)
http://juliusdavies.ca/logging.html

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

RE: [CODEC] Migrate issue from 1.3 to 1.4

[Gary Gregory]

Can you please be more specific? Can you supply a test case?

Thank you,
Gary

 -Original Message-
 From: Murat Yücel [mailto:kodeperke...@gmail.com]
 Sent: Monday, October 26, 2009 13:09
 To: user
 Subject: [CODEC] Migrate issue from 1.3 to 1.4
 
 Hi All
 
 We are currently using commons-codec in our project. We have used this
 version for about one year.
 This means that we have a lot of users in our database with encrypted
 password. We have used the Base64
 class to encode the passwords.
 The problem is that after upgrading to 1.4 none of the users can
 login, so we have made a rollback.
 
 Is this a known issue? I havent find anything on your website.
 
 Regards
 
 /Murat
 
 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org


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

Re: codec - thread safe

[sebb]

On 09/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
 On 10/8/07, sebb [EMAIL PROTECTED] wrote:
  Which methods do you actually need?
 
  If you only need BCodec, then that (and Base64 which it calls) look to
  be thread-safe, so you only need to instantiate it once for each
  different charset.

 Yes, I sort of figured that out for myself already when I first
 started the conversation with Henri. Now thanks for your help, I got
 another pair of eyes confirming this. So I am good in my case.

 But all the discussion has been more about the in general case. I
 just feel that,

 1. Codec as a commons library, it should not be this hard to find out
 about information like this. It should be either this or that, find
 out for yourself is no good situation. As someone else pointed out
 earlier, we could use a better documentation.

Agreed. It should be stated clearly whether or not the code is thread-safe.

 2. It'd be nice for the biz method implementations to be thread safe
 (Ideally in a high performance manner as a value add-on of using a
 commons brand library such that user doesn't have to be too creative
 as some of the suggestions given in this discussion to achieve
 performance). Most of them may already be thread safe. And as it seems
 agreed by all that it's not hard to make them that way if not.

For a library such as codec, I agree that it should be thread-safe by
design. Where this is not possible, the unsafe classes should be
clearly identified.

I don't think it makes sense to separate methods into biz and the rest.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Will Pugh]

sebb wrote:

On 09/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
  

On 10/8/07, sebb [EMAIL PROTECTED] wrote:


Which methods do you actually need?

If you only need BCodec, then that (and Base64 which it calls) look to
be thread-safe, so you only need to instantiate it once for each
different charset.
  

Yes, I sort of figured that out for myself already when I first
started the conversation with Henri. Now thanks for your help, I got
another pair of eyes confirming this. So I am good in my case.

But all the discussion has been more about the in general case. I
just feel that,

1. Codec as a commons library, it should not be this hard to find out
about information like this. It should be either this or that, find
out for yourself is no good situation. As someone else pointed out
earlier, we could use a better documentation.



Agreed. It should be stated clearly whether or not the code is thread-safe.
  

I attached a patch to this bug.

My solution here was to add static methods called
   createThreadSafeCodec

on all the classes that are thread safe.  For a few, this simply returns 
an instance of the object.  For others, it returns an instance of the 
object that overrides the dangerous set* methods.  That way, if anyone 
tried to use it in an unsafe manner, they will deterministically get an 
error.


My patch also adds a blurb in package.html basically saying this.
  

2. It'd be nice for the biz method implementations to be thread safe
(Ideally in a high performance manner as a value add-on of using a
commons brand library such that user doesn't have to be too creative
as some of the suggestions given in this discussion to achieve
performance). Most of them may already be thread safe. And as it seems
agreed by all that it's not hard to make them that way if not.



For a library such as codec, I agree that it should be thread-safe by
design. Where this is not possible, the unsafe classes should be
clearly identified.

I don't think it makes sense to separate methods into biz and the rest.
  

I agree.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[simon]

On Sun, 2007-10-07 at 15:23 -0500, Qingtian Wang wrote:
 Ok, I got the point.
 
 So let's say I wanted to work on this. What's the most effective way to do it?
 
 Search the entire code base line by line trying to ID all the thread
 unsafe points by myself? I guess that's very ineffective compared to
 have an issue open, and have the individual developers who write the
 code to address it - They know what needs to be tweaked without having
 to even spend any time since it's their own code. Or at least, the dev
 team as a whole can come up a list of points that need to be worked
 on. I think that'd be much more effective. Any established channel
 where that can happen?

I would suggest that you just check the classes/methods that you
yourself want to be threadsafe, and make any necessary fixes.

There's no obligation to fix anything else; if somebody needs
thread-safety improvements in a different part, then *they* can do it.

And then piece by piece the software gets better for everyone, using a
process that is both cooperative and fair.

Agreed, this doesn't work for major infrastructure type work, but that
is not the case here; just a method or a class needs to be checked for
safety and maybe a few internal synchronization commands added. Codec
really is pretty simple stuff; it's not necessary to have written the
code in order to understand it.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[sebb]

On 08/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
 On 10/7/07, sebb [EMAIL PROTECTED] wrote:
  On 07/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
   Ok, I got the point.
  
   So let's say I wanted to work on this. What's the most effective way to 
   do it?
 
  You could try running some of the code checking utilities on the library.
 
  For example Findbugs and PMD.
 
  I've done a quick check with FIndbugs, but that has not found any
  synchronisation issues. This is because there are no synchronised
  methods, so it cannot find any inconsistencies.
 
  But it should be possible to configure PMD to find any instance or
  static variables that are modified after construction.
 
  Or indeed you could perhaps try making all such variables final, and
  see whether it's possible to fix the compiler errors - but that might
  be a lot of work.
 
   Search the entire code base line by line trying to ID all the thread
   unsafe points by myself? I guess that's very ineffective compared to
   have an issue open, and have the individual developers who write the
   code to address it - They know what needs to be tweaked without having
   to even spend any time since it's their own code. Or at least, the dev
   team as a whole can come up a list of points that need to be worked
 
  Not necessarily - the code may have been developed over a long period,
  and the original authors may not longer be around. Unless the code has
  been worked on recently, it's possible that no-one has much detailed
  knowledge of the code.

 Wow, if that is really the case with commons codec that no one has
 detailed knowledge of the code, it would suggest to me that no one
 should use it as a off the shell usable product since no one really
 knows what it would do.

I did not write specifically about Commons Codec - I was just pointing
out that any software that has been developed over a long period is
likely to have areas that are unfamiliar to some  or all. Indeed, even
if you wrote the software yourself, would you still be familiar with
it several years later? Or even several months?

This is not just a software problem. Any large or long-lived project
will have areas that are not immediately familiar to anyone.

 I mean, it's one thing to say Here's what our intention what this
 product behaves. But use it at your own risk since there is no
 guarantee of any kind., but it's entirely different thing to say
 Here's a bunch of code, but we don't know how it behaves, you're
 welcome to find out for yourself and play around with it.

That's not the case here.
Does Commons Codec offer any thread-safe guarantees?
If not, then yes, one cannot say how it may behave in multi-threaded mode.
But that does not mean the behaviour is unpredictable in single-threaded usage.

For example, Java's SimpleDateFormat is not thread-safe.
Can one predict exactly what happens in multi-threaded mode?
Probably not.


 To me those two things put a product at two rather different level of
 maturity. If codec falls in the latter, a normal user that needs a
 codec library for their work might as well look some where else or
 roll their own stuff to hand their codec needs, since it'd take same
 or even more time to dig in commons-codec and try to find out what
 exactly it's trying to do.

Not so with Commons Codec, since it is quite a small library.

 -Q




 
   on. I think that'd be much more effective. Any established channel
   where that can happen?
 
  If you find some bugs, then report them via JIRA.
  It helps if you can provide test cases; obviously patches as well is
  even better.
 
   Thanks,
   -Q
  
  
  
   On 10/7/07, Torsten Curdt [EMAIL PROTECTED] wrote:
 Can the dev team make that happen? - a humble request from a user.

 The think about open source is that there is no distinction between
 developer and user.

 That's interesting. Why then almost all open source projects have
 users doc vs. developer doc, users mailing list vs. developers
 mailing list?
   
Point taken. But this is more about the presentation of information.
Still the distinction is blurry as many developers and contributors
come initially from the user background. They felt the itch to
improve the code and ended up providing the fix/feature
themselves ...I guess we are trying to get you to do the same :) You
should see that more as an invitation to help.
   
 The developers develop because they want to use the
 code. And when somebody wants to use a feature that doesn't exist,
 then
 they can develop it.

 In short, if you want this feature, you can do this yourself and
 post a
 patch to this list so it gets included in the next release. There
 is no
 paid dev team for any of the commons code.

 OK i see. My intention was just to bring up an issue/request. There is
 no saying the developers are obligated to work on it. And contributing
 code is certainly 

Re: codec - thread safe

[David J. Biesack]

 Date: Sat, 6 Oct 2007 23:31:19 -0500
 From: Qingtian Wang [EMAIL PROTECTED]
 
 Well, it's pick-your-poison kind of a deal. Either block on one
 instance and take a performance hit, or burn up the memory with lots
 of instances.

Why not compromise? Create a ThreadPoolExecutor of some reasonable size and 
submit a FutureTask
to run the encode or decode, and then do a future.get() when the value is 
needed. You might
even get some concurrency if you can start the encode, then continue doing 
other work
until you need the result.

-- 
David J. Biesack SAS Institute Inc.
(919) 531-7771   SAS Campus Drive
http://www.sas.com   Cary, NC 27513


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: codec - thread safe

[Jörg Schaible]

David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:

 Date: Sat, 6 Oct 2007 23:31:19 -0500
 From: Qingtian Wang [EMAIL PROTECTED]
 
 Well, it's pick-your-poison kind of a deal. Either block on one
 instance and take a performance hit, or burn up the memory with lots
 of instances.
 
 Why not compromise? Create a ThreadPoolExecutor of some
 reasonable size and submit a FutureTask
 to run the encode or decode, and then do a future.get() when
 the value is needed. You might
 even get some concurrency if you can start the encode, then continue
 doing other work until you need the result.

Because it runs on JDK 1.3? However, that's the reason why I argumented not to 
promise thread-safety for any codec and provide synchronization wrappers or a 
user might take the pool approach ... which is quite easy with JDK 5 as you've 
provided here :)

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[David J. Biesack]

 Date: Mon, 8 Oct 2007 16:23:59 +0200
 From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
 
 David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:
 
  Date: Sat, 6 Oct 2007 23:31:19 -0500
  From: Qingtian Wang [EMAIL PROTECTED]
  
  Well, it's pick-your-poison kind of a deal. Either block on one
  instance and take a performance hit, or burn up the memory with lots
  of instances.
  
  Why not compromise? Create a ThreadPoolExecutor ...
 
 Because it runs on JDK 1.3?

The java.util.concurrent backport http://backport-jsr166.sourceforge.net/ runs 
on 1.3, for just this kind of use.

 However, that's the reason why I argumented not to promise thread-safety for 
 any codec and provide synchronization wrappers or a user might take the pool 
 approach ... which is quite easy with JDK 5 as you've provided here :)

I think it makes a lot of sense to document the thread safety attributes of 
Commons libraries.

 - Jörg

-- 
David J. Biesack SAS Institute Inc.
(919) 531-7771   SAS Campus Drive
http://www.sas.com   Cary, NC 27513


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Qingtian Wang]

On 10/8/07, sebb [EMAIL PROTECTED] wrote:
 On 08/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
  On 10/7/07, sebb [EMAIL PROTECTED] wrote:
   On 07/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
Ok, I got the point.
   
So let's say I wanted to work on this. What's the most effective way to 
do it?
  
   You could try running some of the code checking utilities on the library.
  
   For example Findbugs and PMD.
  
   I've done a quick check with FIndbugs, but that has not found any
   synchronisation issues. This is because there are no synchronised
   methods, so it cannot find any inconsistencies.
  
   But it should be possible to configure PMD to find any instance or
   static variables that are modified after construction.
  
   Or indeed you could perhaps try making all such variables final, and
   see whether it's possible to fix the compiler errors - but that might
   be a lot of work.
  
Search the entire code base line by line trying to ID all the thread
unsafe points by myself? I guess that's very ineffective compared to
have an issue open, and have the individual developers who write the
code to address it - They know what needs to be tweaked without having
to even spend any time since it's their own code. Or at least, the dev
team as a whole can come up a list of points that need to be worked
  
   Not necessarily - the code may have been developed over a long period,
   and the original authors may not longer be around. Unless the code has
   been worked on recently, it's possible that no-one has much detailed
   knowledge of the code.
 
  Wow, if that is really the case with commons codec that no one has
  detailed knowledge of the code, it would suggest to me that no one
  should use it as a off the shell usable product since no one really
  knows what it would do.

 I did not write specifically about Commons Codec - I was just pointing
 out that any software that has been developed over a long period is
 likely to have areas that are unfamiliar to some  or all. Indeed, even
 if you wrote the software yourself, would you still be familiar with
 it several years later? Or even several months?

No, admitted I wouldn't. But I do believe, if I am still physically
around, it's easier for me to get back the code I wrote, and ask
myself what the heck was I thinking? than someone tries to do the
same.


 This is not just a software problem. Any large or long-lived project
 will have areas that are not immediately familiar to anyone.

Agreed. But at the same time, trying to fully utilize the available
knowledge base to start with might be beneficial. That's all I am
trying to say.



  I mean, it's one thing to say Here's what our intention what this
  product behaves. But use it at your own risk since there is no
  guarantee of any kind., but it's entirely different thing to say
  Here's a bunch of code, but we don't know how it behaves, you're
  welcome to find out for yourself and play around with it.

 That's not the case here.
 Does Commons Codec offer any thread-safe guarantees?
 If not, then yes, one cannot say how it may behave in multi-threaded mode.
 But that does not mean the behaviour is unpredictable in single-threaded 
 usage.

That's exactly what I was trying to figure out: Is thread-safe an
intention in general for the code base?

And after I found out that the answer is No, and worse, it seems
some methods are thread-safe and others are not, and nobody knows
what's what. That's where I made an issue out of it: Since no body
even knows for sure which is and which not, can we at least try to be
able to say for sure on the existing code base in terms of
thread-safety.

And I'd say before we can be sure of that, tell the users up front: No
thread-safety is considered. To me, that's much better than saying
nothing.



 For example, Java's SimpleDateFormat is not thread-safe.
 Can one predict exactly what happens in multi-threaded mode?
 Probably not.

That is actually a very good example: In the Javadoc of the that
class, Sun says it loud and clear: This not thread-safe. My wish is
simply that codec is able to give those kind of statements, and then
make the main business methods such as encode/decode thread safe,
rather than saying nothing and leave it for the users to find out.



  To me those two things put a product at two rather different level of
  maturity. If codec falls in the latter, a normal user that needs a
  codec library for their work might as well look some where else or
  roll their own stuff to hand their codec needs, since it'd take same
  or even more time to dig in commons-codec and try to find out what
  exactly it's trying to do.

 Not so with Commons Codec, since it is quite a small library.

Well big or small is rather subjective: For a slow developer like
myself in a rush to find a codec library for my work, it's big enough.
:)



  -Q
 
 
 
 
  
on. I think that'd be much more effective. Any established channel

RE: codec - thread safe

[Jörg Schaible]

David J. Biesack wrote on Monday, October 08, 2007 4:40 PM:

 Date: Mon, 8 Oct 2007 16:23:59 +0200
 From: =?iso-8859-1?Q?J=F6rg_Schaible?=
 [EMAIL PROTECTED]
 
 David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:
 
 Date: Sat, 6 Oct 2007 23:31:19 -0500
 From: Qingtian Wang [EMAIL PROTECTED]
 
 Well, it's pick-your-poison kind of a deal. Either block on one
 instance and take a performance hit, or burn up the memory with
 lots of instances.
 
 Why not compromise? Create a ThreadPoolExecutor ...
 
 Because it runs on JDK 1.3?
 
 The java.util.concurrent backport
 http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
 kind of use. 

I know this, but I doubt that we wanna start to depend Apache common components 
on it ;-)

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[David J. Biesack]

 Date: Mon, 8 Oct 2007 17:01:02 +0200
 From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
 
  The java.util.concurrent backport
  http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
  kind of use. 
 
 I know this, but I doubt that we wanna start to depend Apache common 
 components on it ;-)

Agreed; I, like you, was merely suggesting to what Commons consumers might do 
to deal with non-threadsafe codecs.

 - Jörg

-- 
David J. Biesack SAS Institute Inc.
(919) 531-7771   SAS Campus Drive
http://www.sas.com   Cary, NC 27513


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Will Pugh]

David J. Biesack wrote:

Date: Mon, 8 Oct 2007 17:01:02 +0200
From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]



The java.util.concurrent backport
http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
kind of use. 
  

I know this, but I doubt that we wanna start to depend Apache common components 
on it ;-)



Agreed; I, like you, was merely suggesting to what Commons consumers might do 
to deal with non-threadsafe codecs.

  
Might seem like a silly question, but has anyone found anything that 
looks like a threading issue in Codec? 

The code is pretty simple.  I did a quick look through the code, and it 
seemed like everything was pretty thread safe.  It looks like you should 
be O.K. as long as:
   1)  You don't change the parameters to a codec while it's running, 
e.g. changing charsets, etc.
   2)  You should not use a MessageDigest returned by DigestUtils by 
multiple threads.  This should be clear given the API (it's a SUN api)


It also seems to me that the difference between code that you can trust 
as being thread safe, and code you cannot trust as being thread safe has 
a lot to do with whether it is tested for thread safety.  Seems to me 
like another way of helping out here would be to build concurrency tests 
for whichever APIs you are interested using on multiple threads.  Not 
sure where we would put them yet, but seems like the only way to assure 
thread-safety (especially if we could get someone to volunteer running 
them on a big beefy multi-proc machine :).

- Jörg



  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[sebb]

On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:
 David J. Biesack wrote:
  Date: Mon, 8 Oct 2007 17:01:02 +0200
  From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
 
 
  The java.util.concurrent backport
  http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
  kind of use.
 
  I know this, but I doubt that we wanna start to depend Apache common 
  components on it ;-)
 
 
  Agreed; I, like you, was merely suggesting to what Commons consumers might 
  do to deal with non-threadsafe codecs.
 
 
 Might seem like a silly question, but has anyone found anything that
 looks like a threading issue in Codec?

Yes -  QCodec has a public method that sets an instance variable (see
my comments on CODEC-55).

 The code is pretty simple.  I did a quick look through the code, and it
 seemed like everything was pretty thread safe.  It looks like you should
 be O.K. as long as:
1)  You don't change the parameters to a codec while it's running,
 e.g. changing charsets, etc.

See above.

Having said that, I think it would not be too difficult to fix the
classes so that they are thread-safe. Most of the ones I looked at
could even be made invariant.

So their thread-safety would only depend on any external calls they
made; this could presumably be fixed by providing synchronised
versions as suggested earlier.

2)  You should not use a MessageDigest returned by DigestUtils by
 multiple threads.  This should be clear given the API (it's a SUN api)

 It also seems to me that the difference between code that you can trust
 as being thread safe, and code you cannot trust as being thread safe has
 a lot to do with whether it is tested for thread safety.  Seems to me
 like another way of helping out here would be to build concurrency tests
 for whichever APIs you are interested using on multiple threads.  Not
 sure where we would put them yet, but seems like the only way to assure
 thread-safety (especially if we could get someone to volunteer running
 them on a big beefy multi-proc machine :).

Indeed.

  - Jörg
 
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Will Pugh]

Ya know.  Just to put this in a little perspective. 

These objects are pretty small (QCodec has only two members in it), and 
have practically no instantiation cost.  Instantiating these and quickly 
throwing them out is probably not such a bad idea, and may give you 
better performance that doing anything with ThreadLocal.  Java VMs are 
fairly well tuned for dealing with short-lived, small objects (which 
these are).


I can't imagine that many people are using thousands of these per 
request, probably, more on the order of one or two a request?


   --Will

James Carman wrote:

Try using a ThreadLocal variable to store your Encoder/Decoder that
you need to be thread safe.

On 10/8/07, sebb [EMAIL PROTECTED] wrote:
  

On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:


David J. Biesack wrote:
  

Date: Mon, 8 Oct 2007 17:01:02 +0200
From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]


  

The java.util.concurrent backport
http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
kind of use.



I know this, but I doubt that we wanna start to depend Apache common components 
on it ;-)

  

Agreed; I, like you, was merely suggesting to what Commons consumers might do 
to deal with non-threadsafe codecs.




Might seem like a silly question, but has anyone found anything that
looks like a threading issue in Codec?
  

Yes -  QCodec has a public method that sets an instance variable (see
my comments on CODEC-55).



The code is pretty simple.  I did a quick look through the code, and it
seemed like everything was pretty thread safe.  It looks like you should
be O.K. as long as:
   1)  You don't change the parameters to a codec while it's running,
e.g. changing charsets, etc.
  

See above.

Having said that, I think it would not be too difficult to fix the
classes so that they are thread-safe. Most of the ones I looked at
could even be made invariant.

So their thread-safety would only depend on any external calls they
made; this could presumably be fixed by providing synchronised
versions as suggested earlier.



   2)  You should not use a MessageDigest returned by DigestUtils by
multiple threads.  This should be clear given the API (it's a SUN api)

It also seems to me that the difference between code that you can trust
as being thread safe, and code you cannot trust as being thread safe has
a lot to do with whether it is tested for thread safety.  Seems to me
like another way of helping out here would be to build concurrency tests
for whichever APIs you are interested using on multiple threads.  Not
sure where we would put them yet, but seems like the only way to assure
thread-safety (especially if we could get someone to volunteer running
them on a big beefy multi-proc machine :).
  

Indeed.



- Jörg

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[James Carman]

That's kind of what I said on the JIRA issue, too.

On 10/8/07, Will Pugh [EMAIL PROTECTED] wrote:
 Ya know.  Just to put this in a little perspective.

 These objects are pretty small (QCodec has only two members in it), and
 have practically no instantiation cost.  Instantiating these and quickly
 throwing them out is probably not such a bad idea, and may give you
 better performance that doing anything with ThreadLocal.  Java VMs are
 fairly well tuned for dealing with short-lived, small objects (which
 these are).

 I can't imagine that many people are using thousands of these per
 request, probably, more on the order of one or two a request?

 --Will

 James Carman wrote:
  Try using a ThreadLocal variable to store your Encoder/Decoder that
  you need to be thread safe.
 
  On 10/8/07, sebb [EMAIL PROTECTED] wrote:
 
  On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:
 
  David J. Biesack wrote:
 
  Date: Mon, 8 Oct 2007 17:01:02 +0200
  From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
 
 
 
  The java.util.concurrent backport
  http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
  kind of use.
 
 
  I know this, but I doubt that we wanna start to depend Apache common 
  components on it ;-)
 
 
  Agreed; I, like you, was merely suggesting to what Commons consumers 
  might do to deal with non-threadsafe codecs.
 
 
 
  Might seem like a silly question, but has anyone found anything that
  looks like a threading issue in Codec?
 
  Yes -  QCodec has a public method that sets an instance variable (see
  my comments on CODEC-55).
 
 
  The code is pretty simple.  I did a quick look through the code, and it
  seemed like everything was pretty thread safe.  It looks like you should
  be O.K. as long as:
 1)  You don't change the parameters to a codec while it's running,
  e.g. changing charsets, etc.
 
  See above.
 
  Having said that, I think it would not be too difficult to fix the
  classes so that they are thread-safe. Most of the ones I looked at
  could even be made invariant.
 
  So their thread-safety would only depend on any external calls they
  made; this could presumably be fixed by providing synchronised
  versions as suggested earlier.
 
 
 2)  You should not use a MessageDigest returned by DigestUtils by
  multiple threads.  This should be clear given the API (it's a SUN api)
 
  It also seems to me that the difference between code that you can trust
  as being thread safe, and code you cannot trust as being thread safe has
  a lot to do with whether it is tested for thread safety.  Seems to me
  like another way of helping out here would be to build concurrency tests
  for whichever APIs you are interested using on multiple threads.  Not
  sure where we would put them yet, but seems like the only way to assure
  thread-safety (especially if we could get someone to volunteer running
  them on a big beefy multi-proc machine :).
 
  Indeed.
 
 
  - Jörg
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Qingtian Wang]

The SLA of the project I am working on is 2000 transactions per
second. And I need to decode a 1K string on each request.

-Q



On 10/8/07, Will Pugh [EMAIL PROTECTED] wrote:
 Ya know.  Just to put this in a little perspective.

 These objects are pretty small (QCodec has only two members in it), and
 have practically no instantiation cost.  Instantiating these and quickly
 throwing them out is probably not such a bad idea, and may give you
 better performance that doing anything with ThreadLocal.  Java VMs are
 fairly well tuned for dealing with short-lived, small objects (which
 these are).

 I can't imagine that many people are using thousands of these per
 request, probably, more on the order of one or two a request?

 --Will

 James Carman wrote:
  Try using a ThreadLocal variable to store your Encoder/Decoder that
  you need to be thread safe.
 
  On 10/8/07, sebb [EMAIL PROTECTED] wrote:
 
  On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:
 
  David J. Biesack wrote:
 
  Date: Mon, 8 Oct 2007 17:01:02 +0200
  From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
 
 
 
  The java.util.concurrent backport
  http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
  kind of use.
 
 
  I know this, but I doubt that we wanna start to depend Apache common 
  components on it ;-)
 
 
  Agreed; I, like you, was merely suggesting to what Commons consumers 
  might do to deal with non-threadsafe codecs.
 
 
 
  Might seem like a silly question, but has anyone found anything that
  looks like a threading issue in Codec?
 
  Yes -  QCodec has a public method that sets an instance variable (see
  my comments on CODEC-55).
 
 
  The code is pretty simple.  I did a quick look through the code, and it
  seemed like everything was pretty thread safe.  It looks like you should
  be O.K. as long as:
 1)  You don't change the parameters to a codec while it's running,
  e.g. changing charsets, etc.
 
  See above.
 
  Having said that, I think it would not be too difficult to fix the
  classes so that they are thread-safe. Most of the ones I looked at
  could even be made invariant.
 
  So their thread-safety would only depend on any external calls they
  made; this could presumably be fixed by providing synchronised
  versions as suggested earlier.
 
 
 2)  You should not use a MessageDigest returned by DigestUtils by
  multiple threads.  This should be clear given the API (it's a SUN api)
 
  It also seems to me that the difference between code that you can trust
  as being thread safe, and code you cannot trust as being thread safe has
  a lot to do with whether it is tested for thread safety.  Seems to me
  like another way of helping out here would be to build concurrency tests
  for whichever APIs you are interested using on multiple threads.  Not
  sure where we would put them yet, but seems like the only way to assure
  thread-safety (especially if we could get someone to volunteer running
  them on a big beefy multi-proc machine :).
 
  Indeed.
 
 
  - Jörg
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[sebb]

Which methods do you actually need?

If you only need BCodec, then that (and Base64 which it calls) look to
be thread-safe, so you only need to instantiate it once for each
different charset.

On 08/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
 The SLA of the project I am working on is 2000 transactions per
 second. And I need to decode a 1K string on each request.

 -Q



 On 10/8/07, Will Pugh [EMAIL PROTECTED] wrote:
  Ya know.  Just to put this in a little perspective.
 
  These objects are pretty small (QCodec has only two members in it), and
  have practically no instantiation cost.  Instantiating these and quickly
  throwing them out is probably not such a bad idea, and may give you
  better performance that doing anything with ThreadLocal.  Java VMs are
  fairly well tuned for dealing with short-lived, small objects (which
  these are).
 
  I can't imagine that many people are using thousands of these per
  request, probably, more on the order of one or two a request?
 
  --Will
 
  James Carman wrote:
   Try using a ThreadLocal variable to store your Encoder/Decoder that
   you need to be thread safe.
  
   On 10/8/07, sebb [EMAIL PROTECTED] wrote:
  
   On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:
  
   David J. Biesack wrote:
  
   Date: Mon, 8 Oct 2007 17:01:02 +0200
   From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
  
  
  
   The java.util.concurrent backport
   http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
   kind of use.
  
  
   I know this, but I doubt that we wanna start to depend Apache common 
   components on it ;-)
  
  
   Agreed; I, like you, was merely suggesting to what Commons consumers 
   might do to deal with non-threadsafe codecs.
  
  
  
   Might seem like a silly question, but has anyone found anything that
   looks like a threading issue in Codec?
  
   Yes -  QCodec has a public method that sets an instance variable (see
   my comments on CODEC-55).
  
  
   The code is pretty simple.  I did a quick look through the code, and it
   seemed like everything was pretty thread safe.  It looks like you should
   be O.K. as long as:
  1)  You don't change the parameters to a codec while it's running,
   e.g. changing charsets, etc.
  
   See above.
  
   Having said that, I think it would not be too difficult to fix the
   classes so that they are thread-safe. Most of the ones I looked at
   could even be made invariant.
  
   So their thread-safety would only depend on any external calls they
   made; this could presumably be fixed by providing synchronised
   versions as suggested earlier.
  
  
  2)  You should not use a MessageDigest returned by DigestUtils by
   multiple threads.  This should be clear given the API (it's a SUN api)
  
   It also seems to me that the difference between code that you can trust
   as being thread safe, and code you cannot trust as being thread safe has
   a lot to do with whether it is tested for thread safety.  Seems to me
   like another way of helping out here would be to build concurrency tests
   for whichever APIs you are interested using on multiple threads.  Not
   sure where we would put them yet, but seems like the only way to assure
   thread-safety (especially if we could get someone to volunteer running
   them on a big beefy multi-proc machine :).
  
   Indeed.
  
  
   - Jörg
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[James Carman]

And, a simple map would suffice in that case (lazy-initialized of
course).  If you need QCodec, then you'd have in incorporate the
encodeBlanks and the charset into the map's key (if you really have
cases where you do/do not want to encode blanks).

On 10/8/07, sebb [EMAIL PROTECTED] wrote:
 Which methods do you actually need?

 If you only need BCodec, then that (and Base64 which it calls) look to
 be thread-safe, so you only need to instantiate it once for each
 different charset.

 On 08/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
  The SLA of the project I am working on is 2000 transactions per
  second. And I need to decode a 1K string on each request.
 
  -Q
 
 
 
  On 10/8/07, Will Pugh [EMAIL PROTECTED] wrote:
   Ya know.  Just to put this in a little perspective.
  
   These objects are pretty small (QCodec has only two members in it), and
   have practically no instantiation cost.  Instantiating these and quickly
   throwing them out is probably not such a bad idea, and may give you
   better performance that doing anything with ThreadLocal.  Java VMs are
   fairly well tuned for dealing with short-lived, small objects (which
   these are).
  
   I can't imagine that many people are using thousands of these per
   request, probably, more on the order of one or two a request?
  
   --Will
  
   James Carman wrote:
Try using a ThreadLocal variable to store your Encoder/Decoder that
you need to be thread safe.
   
On 10/8/07, sebb [EMAIL PROTECTED] wrote:
   
On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:
   
David J. Biesack wrote:
   
Date: Mon, 8 Oct 2007 17:01:02 +0200
From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
   
   
   
The java.util.concurrent backport
http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
kind of use.
   
   
I know this, but I doubt that we wanna start to depend Apache 
common components on it ;-)
   
   
Agreed; I, like you, was merely suggesting to what Commons consumers 
might do to deal with non-threadsafe codecs.
   
   
   
Might seem like a silly question, but has anyone found anything that
looks like a threading issue in Codec?
   
Yes -  QCodec has a public method that sets an instance variable (see
my comments on CODEC-55).
   
   
The code is pretty simple.  I did a quick look through the code, and 
it
seemed like everything was pretty thread safe.  It looks like you 
should
be O.K. as long as:
   1)  You don't change the parameters to a codec while it's running,
e.g. changing charsets, etc.
   
See above.
   
Having said that, I think it would not be too difficult to fix the
classes so that they are thread-safe. Most of the ones I looked at
could even be made invariant.
   
So their thread-safety would only depend on any external calls they
made; this could presumably be fixed by providing synchronised
versions as suggested earlier.
   
   
   2)  You should not use a MessageDigest returned by DigestUtils by
multiple threads.  This should be clear given the API (it's a SUN api)
   
It also seems to me that the difference between code that you can 
trust
as being thread safe, and code you cannot trust as being thread safe 
has
a lot to do with whether it is tested for thread safety.  Seems to me
like another way of helping out here would be to build concurrency 
tests
for whichever APIs you are interested using on multiple threads.  Not
sure where we would put them yet, but seems like the only way to 
assure
thread-safety (especially if we could get someone to volunteer running
them on a big beefy multi-proc machine :).
   
Indeed.
   
   
- Jörg
   
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL 

Re: codec - thread safe

[sebb]

Or take a copy of QCodec and fix it to remove the offending code...

The change would be more difficult to make in the codec library,
because removing the offending method would not be backwards
compatible.

On 09/10/2007, James Carman [EMAIL PROTECTED] wrote:
 And, a simple map would suffice in that case (lazy-initialized of
 course).  If you need QCodec, then you'd have in incorporate the
 encodeBlanks and the charset into the map's key (if you really have
 cases where you do/do not want to encode blanks).

 On 10/8/07, sebb [EMAIL PROTECTED] wrote:
  Which methods do you actually need?
 
  If you only need BCodec, then that (and Base64 which it calls) look to
  be thread-safe, so you only need to instantiate it once for each
  different charset.
 
  On 08/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
   The SLA of the project I am working on is 2000 transactions per
   second. And I need to decode a 1K string on each request.
  
   -Q
  
  
  
   On 10/8/07, Will Pugh [EMAIL PROTECTED] wrote:
Ya know.  Just to put this in a little perspective.
   
These objects are pretty small (QCodec has only two members in it), and
have practically no instantiation cost.  Instantiating these and quickly
throwing them out is probably not such a bad idea, and may give you
better performance that doing anything with ThreadLocal.  Java VMs are
fairly well tuned for dealing with short-lived, small objects (which
these are).
   
I can't imagine that many people are using thousands of these per
request, probably, more on the order of one or two a request?
   
--Will
   
James Carman wrote:
 Try using a ThreadLocal variable to store your Encoder/Decoder that
 you need to be thread safe.

 On 10/8/07, sebb [EMAIL PROTECTED] wrote:

 On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:

 David J. Biesack wrote:

 Date: Mon, 8 Oct 2007 17:01:02 +0200
 From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]



 The java.util.concurrent backport
 http://backport-jsr166.sourceforge.net/ runs on 1.3, for just 
 this
 kind of use.


 I know this, but I doubt that we wanna start to depend Apache 
 common components on it ;-)


 Agreed; I, like you, was merely suggesting to what Commons 
 consumers might do to deal with non-threadsafe codecs.



 Might seem like a silly question, but has anyone found anything that
 looks like a threading issue in Codec?

 Yes -  QCodec has a public method that sets an instance variable (see
 my comments on CODEC-55).


 The code is pretty simple.  I did a quick look through the code, 
 and it
 seemed like everything was pretty thread safe.  It looks like you 
 should
 be O.K. as long as:
1)  You don't change the parameters to a codec while it's 
 running,
 e.g. changing charsets, etc.

 See above.

 Having said that, I think it would not be too difficult to fix the
 classes so that they are thread-safe. Most of the ones I looked at
 could even be made invariant.

 So their thread-safety would only depend on any external calls they
 made; this could presumably be fixed by providing synchronised
 versions as suggested earlier.


2)  You should not use a MessageDigest returned by DigestUtils by
 multiple threads.  This should be clear given the API (it's a SUN 
 api)

 It also seems to me that the difference between code that you can 
 trust
 as being thread safe, and code you cannot trust as being thread 
 safe has
 a lot to do with whether it is tested for thread safety.  Seems to 
 me
 like another way of helping out here would be to build concurrency 
 tests
 for whichever APIs you are interested using on multiple threads.  
 Not
 sure where we would put them yet, but seems like the only way to 
 assure
 thread-safety (especially if we could get someone to volunteer 
 running
 them on a big beefy multi-proc machine :).

 Indeed.


 - Jörg



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
   

Re: codec - thread safe

[Qingtian Wang]

On 10/8/07, sebb [EMAIL PROTECTED] wrote:
 Which methods do you actually need?

 If you only need BCodec, then that (and Base64 which it calls) look to
 be thread-safe, so you only need to instantiate it once for each
 different charset.

Yes, I sort of figured that out for myself already when I first
started the conversation with Henri. Now thanks for your help, I got
another pair of eyes confirming this. So I am good in my case.

But all the discussion has been more about the in general case. I
just feel that,

1. Codec as a commons library, it should not be this hard to find out
about information like this. It should be either this or that, find
out for yourself is no good situation. As someone else pointed out
earlier, we could use a better documentation.

2. It'd be nice for the biz method implementations to be thread safe
(Ideally in a high performance manner as a value add-on of using a
commons brand library such that user doesn't have to be too creative
as some of the suggestions given in this discussion to achieve
performance). Most of them may already be thread safe. And as it seems
agreed by all that it's not hard to make them that way if not.

Thanks to all for your help!
-Q



 On 08/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
  The SLA of the project I am working on is 2000 transactions per
  second. And I need to decode a 1K string on each request.
 
  -Q
 
 
 
  On 10/8/07, Will Pugh [EMAIL PROTECTED] wrote:
   Ya know.  Just to put this in a little perspective.
  
   These objects are pretty small (QCodec has only two members in it), and
   have practically no instantiation cost.  Instantiating these and quickly
   throwing them out is probably not such a bad idea, and may give you
   better performance that doing anything with ThreadLocal.  Java VMs are
   fairly well tuned for dealing with short-lived, small objects (which
   these are).
  
   I can't imagine that many people are using thousands of these per
   request, probably, more on the order of one or two a request?
  
   --Will
  
   James Carman wrote:
Try using a ThreadLocal variable to store your Encoder/Decoder that
you need to be thread safe.
   
On 10/8/07, sebb [EMAIL PROTECTED] wrote:
   
On 08/10/2007, Will Pugh [EMAIL PROTECTED] wrote:
   
David J. Biesack wrote:
   
Date: Mon, 8 Oct 2007 17:01:02 +0200
From: =?iso-8859-1?Q?J=F6rg_Schaible?= [EMAIL PROTECTED]
   
   
   
The java.util.concurrent backport
http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this
kind of use.
   
   
I know this, but I doubt that we wanna start to depend Apache 
common components on it ;-)
   
   
Agreed; I, like you, was merely suggesting to what Commons consumers 
might do to deal with non-threadsafe codecs.
   
   
   
Might seem like a silly question, but has anyone found anything that
looks like a threading issue in Codec?
   
Yes -  QCodec has a public method that sets an instance variable (see
my comments on CODEC-55).
   
   
The code is pretty simple.  I did a quick look through the code, and 
it
seemed like everything was pretty thread safe.  It looks like you 
should
be O.K. as long as:
   1)  You don't change the parameters to a codec while it's running,
e.g. changing charsets, etc.
   
See above.
   
Having said that, I think it would not be too difficult to fix the
classes so that they are thread-safe. Most of the ones I looked at
could even be made invariant.
   
So their thread-safety would only depend on any external calls they
made; this could presumably be fixed by providing synchronised
versions as suggested earlier.
   
   
   2)  You should not use a MessageDigest returned by DigestUtils by
multiple threads.  This should be clear given the API (it's a SUN api)
   
It also seems to me that the difference between code that you can 
trust
as being thread safe, and code you cannot trust as being thread safe 
has
a lot to do with whether it is tested for thread safety.  Seems to me
like another way of helping out here would be to build concurrency 
tests
for whichever APIs you are interested using on multiple threads.  Not
sure where we would put them yet, but seems like the only way to 
assure
thread-safety (especially if we could get someone to volunteer running
them on a big beefy multi-proc machine :).
   
Indeed.
   
   
- Jörg
   
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
   
-
To unsubscribe, 

Re: codec - thread safe

[sebb]

On 07/10/2007, simon [EMAIL PROTECTED] wrote:
 On Sat, 2007-10-06 at 23:31 -0500, Qingtian Wang wrote:
  Well, it's pick-your-poison kind of a deal. Either block on one
  instance and take a performance hit, or burn up the memory with lots
  of instances.
 
  But in the case of BCodec, I think encode/decode is thread safe.
  Unfortunately per Henri, that's not generally true for others.
 
  Well, let me make it clear that I am a total layman on codec. But it
  seems to me it's not that difficult to implement all the codec methods
  in a thread safe manner, without sync blocks.
 
  Can the dev team make that happen? - a humble request from a user.

 The think about open source is that there is no distinction between
 developer and user. The developers develop because they want to use the
 code. And when somebody wants to use a feature that doesn't exist, then
 they can develop it.

 In short, if you want this feature, you can do this yourself and post a
 patch to this list so it gets included in the next release. There is no
 paid dev team for any of the commons code.

Might be better to create a JIRA issue and attach the patch to that:
* others can easily see that the issue has been reported
* patches can get mangled when posted to lists, and are more difficult
to keep track of.

For Codec, start here:
http://commons.apache.org/codec/issue-tracking.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Qingtian Wang]

On 10/7/07, simon [EMAIL PROTECTED] wrote:
 On Sat, 2007-10-06 at 23:31 -0500, Qingtian Wang wrote:
  Well, it's pick-your-poison kind of a deal. Either block on one
  instance and take a performance hit, or burn up the memory with lots
  of instances.
 
  But in the case of BCodec, I think encode/decode is thread safe.
  Unfortunately per Henri, that's not generally true for others.
 
  Well, let me make it clear that I am a total layman on codec. But it
  seems to me it's not that difficult to implement all the codec methods
  in a thread safe manner, without sync blocks.
 
  Can the dev team make that happen? - a humble request from a user.

 The think about open source is that there is no distinction between
 developer and user.

That's interesting. Why then almost all open source projects have
users doc vs. developer doc, users mailing list vs. developers
mailing list?

 The developers develop because they want to use the
 code. And when somebody wants to use a feature that doesn't exist, then
 they can develop it.

 In short, if you want this feature, you can do this yourself and post a
 patch to this list so it gets included in the next release. There is no
 paid dev team for any of the commons code.

OK i see. My intention was just to bring up an issue/request. There is
no saying the developers are obligated to work on it. And contributing
code is certainly not the only way of involving with an open source
project. Nevertheless, if the dev team (unpaid as I understand it)
wants the project to be more popular, it might help listening to what
other users have to say other than themselves; otherwise just forget
about it.

-Q







 Regards,

 Simon


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Torsten Curdt]

Can the dev team make that happen? - a humble request from a user.


The think about open source is that there is no distinction between
developer and user.


That's interesting. Why then almost all open source projects have
users doc vs. developer doc, users mailing list vs. developers
mailing list?


Point taken. But this is more about the presentation of information.  
Still the distinction is blurry as many developers and contributors  
come initially from the user background. They felt the itch to  
improve the code and ended up providing the fix/feature  
themselves ...I guess we are trying to get you to do the same :) You  
should see that more as an invitation to help.



The developers develop because they want to use the
code. And when somebody wants to use a feature that doesn't exist,  
then

they can develop it.

In short, if you want this feature, you can do this yourself and  
post a
patch to this list so it gets included in the next release. There  
is no

paid dev team for any of the commons code.


OK i see. My intention was just to bring up an issue/request. There is
no saying the developers are obligated to work on it. And contributing
code is certainly not the only way of involving with an open source
project.


That is of course true. But I guess what Simon was wanting to point  
out is that requesting a feature rarely means it gets done unless a  
developer needs that feature too. The personal TODO lists are usually  
very long. So usually you are better of contributing a patch  
yourself ...or pay someone to do it for you. That's how it works.



Nevertheless, if the dev team (unpaid as I understand it)
wants the project to be more popular, it might help listening to what
other users have to say other than themselves; otherwise just forget
about it.


Well, sure ...listening is great - but someone gotta do it.
There is no us vs you, no dev vs user there is just us.

Does that make sense?

cheers
--
Torsten

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Qingtian Wang]

Ok, I got the point.

So let's say I wanted to work on this. What's the most effective way to do it?

Search the entire code base line by line trying to ID all the thread
unsafe points by myself? I guess that's very ineffective compared to
have an issue open, and have the individual developers who write the
code to address it - They know what needs to be tweaked without having
to even spend any time since it's their own code. Or at least, the dev
team as a whole can come up a list of points that need to be worked
on. I think that'd be much more effective. Any established channel
where that can happen?

Thanks,
-Q



On 10/7/07, Torsten Curdt [EMAIL PROTECTED] wrote:
  Can the dev team make that happen? - a humble request from a user.
 
  The think about open source is that there is no distinction between
  developer and user.
 
  That's interesting. Why then almost all open source projects have
  users doc vs. developer doc, users mailing list vs. developers
  mailing list?

 Point taken. But this is more about the presentation of information.
 Still the distinction is blurry as many developers and contributors
 come initially from the user background. They felt the itch to
 improve the code and ended up providing the fix/feature
 themselves ...I guess we are trying to get you to do the same :) You
 should see that more as an invitation to help.

  The developers develop because they want to use the
  code. And when somebody wants to use a feature that doesn't exist,
  then
  they can develop it.
 
  In short, if you want this feature, you can do this yourself and
  post a
  patch to this list so it gets included in the next release. There
  is no
  paid dev team for any of the commons code.
 
  OK i see. My intention was just to bring up an issue/request. There is
  no saying the developers are obligated to work on it. And contributing
  code is certainly not the only way of involving with an open source
  project.

 That is of course true. But I guess what Simon was wanting to point
 out is that requesting a feature rarely means it gets done unless a
 developer needs that feature too. The personal TODO lists are usually
 very long. So usually you are better of contributing a patch
 yourself ...or pay someone to do it for you. That's how it works.

  Nevertheless, if the dev team (unpaid as I understand it)
  wants the project to be more popular, it might help listening to what
  other users have to say other than themselves; otherwise just forget
  about it.

 Well, sure ...listening is great - but someone gotta do it.
 There is no us vs you, no dev vs user there is just us.

 Does that make sense?

 cheers
 --
 Torsten

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[sebb]

On 07/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
 Ok, I got the point.

 So let's say I wanted to work on this. What's the most effective way to do it?

You could try running some of the code checking utilities on the library.

For example Findbugs and PMD.

I've done a quick check with FIndbugs, but that has not found any
synchronisation issues. This is because there are no synchronised
methods, so it cannot find any inconsistencies.

But it should be possible to configure PMD to find any instance or
static variables that are modified after construction.

Or indeed you could perhaps try making all such variables final, and
see whether it's possible to fix the compiler errors - but that might
be a lot of work.

 Search the entire code base line by line trying to ID all the thread
 unsafe points by myself? I guess that's very ineffective compared to
 have an issue open, and have the individual developers who write the
 code to address it - They know what needs to be tweaked without having
 to even spend any time since it's their own code. Or at least, the dev
 team as a whole can come up a list of points that need to be worked

Not necessarily - the code may have been developed over a long period,
and the original authors may not longer be around. Unless the code has
been worked on recently, it's possible that no-one has much detailed
knowledge of the code.

 on. I think that'd be much more effective. Any established channel
 where that can happen?

If you find some bugs, then report them via JIRA.
It helps if you can provide test cases; obviously patches as well is
even better.

 Thanks,
 -Q



 On 10/7/07, Torsten Curdt [EMAIL PROTECTED] wrote:
   Can the dev team make that happen? - a humble request from a user.
  
   The think about open source is that there is no distinction between
   developer and user.
  
   That's interesting. Why then almost all open source projects have
   users doc vs. developer doc, users mailing list vs. developers
   mailing list?
 
  Point taken. But this is more about the presentation of information.
  Still the distinction is blurry as many developers and contributors
  come initially from the user background. They felt the itch to
  improve the code and ended up providing the fix/feature
  themselves ...I guess we are trying to get you to do the same :) You
  should see that more as an invitation to help.
 
   The developers develop because they want to use the
   code. And when somebody wants to use a feature that doesn't exist,
   then
   they can develop it.
  
   In short, if you want this feature, you can do this yourself and
   post a
   patch to this list so it gets included in the next release. There
   is no
   paid dev team for any of the commons code.
  
   OK i see. My intention was just to bring up an issue/request. There is
   no saying the developers are obligated to work on it. And contributing
   code is certainly not the only way of involving with an open source
   project.
 
  That is of course true. But I guess what Simon was wanting to point
  out is that requesting a feature rarely means it gets done unless a
  developer needs that feature too. The personal TODO lists are usually
  very long. So usually you are better of contributing a patch
  yourself ...or pay someone to do it for you. That's how it works.
 
   Nevertheless, if the dev team (unpaid as I understand it)
   wants the project to be more popular, it might help listening to what
   other users have to say other than themselves; otherwise just forget
   about it.
 
  Well, sure ...listening is great - but someone gotta do it.
  There is no us vs you, no dev vs user there is just us.
 
  Does that make sense?
 
  cheers
  --
  Torsten
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: codec - thread safe

[Qingtian Wang]

On 10/7/07, sebb [EMAIL PROTECTED] wrote:
 On 07/10/2007, Qingtian Wang [EMAIL PROTECTED] wrote:
  Ok, I got the point.
 
  So let's say I wanted to work on this. What's the most effective way to do 
  it?

 You could try running some of the code checking utilities on the library.

 For example Findbugs and PMD.

 I've done a quick check with FIndbugs, but that has not found any
 synchronisation issues. This is because there are no synchronised
 methods, so it cannot find any inconsistencies.

 But it should be possible to configure PMD to find any instance or
 static variables that are modified after construction.

 Or indeed you could perhaps try making all such variables final, and
 see whether it's possible to fix the compiler errors - but that might
 be a lot of work.

  Search the entire code base line by line trying to ID all the thread
  unsafe points by myself? I guess that's very ineffective compared to
  have an issue open, and have the individual developers who write the
  code to address it - They know what needs to be tweaked without having
  to even spend any time since it's their own code. Or at least, the dev
  team as a whole can come up a list of points that need to be worked

 Not necessarily - the code may have been developed over a long period,
 and the original authors may not longer be around. Unless the code has
 been worked on recently, it's possible that no-one has much detailed
 knowledge of the code.

Wow, if that is really the case with commons codec that no one has
detailed knowledge of the code, it would suggest to me that no one
should use it as a off the shell usable product since no one really
knows what it would do.

I mean, it's one thing to say Here's what our intention what this
product behaves. But use it at your own risk since there is no
guarantee of any kind., but it's entirely different thing to say
Here's a bunch of code, but we don't know how it behaves, you're
welcome to find out for yourself and play around with it.

To me those two things put a product at two rather different level of
maturity. If codec falls in the latter, a normal user that needs a
codec library for their work might as well look some where else or
roll their own stuff to hand their codec needs, since it'd take same
or even more time to dig in commons-codec and try to find out what
exactly it's trying to do.

-Q





  on. I think that'd be much more effective. Any established channel
  where that can happen?

 If you find some bugs, then report them via JIRA.
 It helps if you can provide test cases; obviously patches as well is
 even better.

  Thanks,
  -Q
 
 
 
  On 10/7/07, Torsten Curdt [EMAIL PROTECTED] wrote:
Can the dev team make that happen? - a humble request from a user.
   
The think about open source is that there is no distinction between
developer and user.
   
That's interesting. Why then almost all open source projects have
users doc vs. developer doc, users mailing list vs. developers
mailing list?
  
   Point taken. But this is more about the presentation of information.
   Still the distinction is blurry as many developers and contributors
   come initially from the user background. They felt the itch to
   improve the code and ended up providing the fix/feature
   themselves ...I guess we are trying to get you to do the same :) You
   should see that more as an invitation to help.
  
The developers develop because they want to use the
code. And when somebody wants to use a feature that doesn't exist,
then
they can develop it.
   
In short, if you want this feature, you can do this yourself and
post a
patch to this list so it gets included in the next release. There
is no
paid dev team for any of the commons code.
   
OK i see. My intention was just to bring up an issue/request. There is
no saying the developers are obligated to work on it. And contributing
code is certainly not the only way of involving with an open source
project.
  
   That is of course true. But I guess what Simon was wanting to point
   out is that requesting a feature rarely means it gets done unless a
   developer needs that feature too. The personal TODO lists are usually
   very long. So usually you are better of contributing a patch
   yourself ...or pay someone to do it for you. That's how it works.
  
Nevertheless, if the dev team (unpaid as I understand it)
wants the project to be more popular, it might help listening to what
other users have to say other than themselves; otherwise just forget
about it.
  
   Well, sure ...listening is great - but someone gotta do it.
   There is no us vs you, no dev vs user there is just us.
  
   Does that make sense?
  
   cheers
   --
   Torsten
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  

Re: codec - thread safe

[Qingtian Wang]

Well, it's pick-your-poison kind of a deal. Either block on one
instance and take a performance hit, or burn up the memory with lots
of instances.

But in the case of BCodec, I think encode/decode is thread safe.
Unfortunately per Henri, that's not generally true for others.

Well, let me make it clear that I am a total layman on codec. But it
seems to me it's not that difficult to implement all the codec methods
in a thread safe manner, without sync blocks.

Can the dev team make that happen? - a humble request from a user.

Thanks,
-Q




On 10/6/07, ben short [EMAIL PROTECTED] wrote:
 How about...

 MyStringCodec {
BCodec delegate = new BCodec();

String encode(String in) {

String result = null;

synchronized(delegate)
{
result = delegate.encode(in);
}

return result;

}
 }


 On 10/6/07, Qingtian Wang [EMAIL PROTECTED] wrote:
  Henri,
 
  That was an unpleasant surprise.
 
  So what would be the general suggested program pattern to use the API
  if one wants to be thread safe?
 
  Is it 1:
 
  MyStringCodec {
  String encode(String in) {
  return new BCodec().encode(in);
  }
  }
 
  or 2:
 
  MyStringCodec {
  BCodec delegate = new BCodec();
 
  String encode(String in) {
  return delegate.encode(in);
  }
  }
 
  Option 2 apparently won't work in a multi-thread scenario if BCodec is
  thread unsafe. But option 1 really creates A LOT of BCodec objects in
  memory
 
  -Q
 
 
 
 
  On 10/5/07, Henri Yandell [EMAIL PROTECTED] wrote:
   On 9/29/07, Qingtian Wang [EMAIL PROTECTED] wrote:
I apologize for this question as it must have been asked a million
times: I was unable to search the mailing list archive for this.
   
Are all the encode/decode methods in commons-codec intended to be 
thread safe?
   
I peeked into the source code for a couple of those methods. They both
seem to be thread safe. But I'd rather ask here to make sure that's
the general intention when the code is written.
  
   I think you'll find it varies. The various algorithms come from
   different sources, and though a common interface was put on them all,
   I doubt that time was spent to make sure they were all threadsafe.
  
   Looking at the objects, I see a few with private attributes that are
   set at more than just construction time - so very likely that one or
   another is thread unsafe.
  
   Hen
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]