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
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:
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
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
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()
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
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
>
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
-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
-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
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
'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
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:
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
--
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
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);
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
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
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
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.
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
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
-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
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
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
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.
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
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
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
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
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
51 matches
Mail list logo
