Hi,
Conceptually, a 'charset' (in java) is a pair of transformations from
bytes to utf-16 code units and vice versa. Could it be useful to have
charset implementations that convert from bytes to the hex (or base64)
representations of those? The idea is as follows:
"0a0b0c".getBytes(HexCharse
Hi Bhaktavatsal Reddy,
your change looks good. I can sponsor it.
Just waiting for a second review...
Thank you and best regards,
Volker
On Mon, Apr 30, 2018 at 11:29 AM, Bhaktavatsal R Maram
wrote:
> Hi All,
>
> Please review the fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8202329
On 02/05/2018 09:35, Jonas Konrad wrote:
Hi,
Conceptually, a 'charset' (in java) is a pair of transformations from
bytes to utf-16 code units and vice versa. Could it be useful to have
charset implementations that convert from bytes to the hex (or base64)
representations of those? The idea is
I did not know about the old HexDumpEncoder. It extends an internal
class `CharacterEncoder` which seems to be pretty similar purpose-wise
to what I am suggesting with CharsetEncoder. There is also the good old
`DatatypeConverter.printHexBinary`, though it can't stream.
But this is not really
Hi,
Could you please review the following fix for jdk11?
bug: https://bugs.openjdk.java.net/browse/JDK-8202544
webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/
The following exported functions in libzip are not used:
ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read
Looks good to me, FWIW.
/Magnus
> 2 maj 2018 kl. 13:52 skrev Alexey Ivanov :
>
> Hi,
>
> Could you please review the following fix for jdk11?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8202544
> webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/
>
> The following expo
Hi,
On 2018-04-30 23:50, David Holmes wrote:
Hi Claes,
On 30/04/2018 10:49 PM, Claes Redestad wrote:
Webrev: http://cr.openjdk.java.net/~redestad/8187123/open.02/
Given String's are immune to unsafe publication races, you should be
able to drop the volatile modifiers. That might save a few
On 2018-04-30 23:28, Paul Sandoz wrote:
I am not quite 100% sure but you could probably replace the null sentinel value
with “/“ or opportunistically “[]”, but i cannot quite tell what exactly is an
invalid binary name. Anyway that is not important.
I tried reading the relevant parts of the
Hi,
a small follow-up to JDK-8202184 in line with Peter Levart's suggestion,
where we can avoid
instantiating two different SpeciesData objects, and should avoid
creating an instance of
the Function on each lookup:
Webrev: http://cr.openjdk.java.net/~redestad/8202548/open.00/
Bug: https://bug
> On May 2, 2018, at 4:35 PM, Jonas Konrad wrote:
>
> "0a0b0c".getBytes(HexCharset.getInstance()) = new byte[] { 0x0a, 0x0b, 0x0c }
> new String(new byte[] { 0x0a, 0x0b, 0x0c }, HexCharset.getInstance()) =
> "0a0b0c"
Normally a charset is to encode a string to byte[], but here you can actuall
The CSR [1] of [2] is now available for review.
If you have comments, please reply to this thread. If you have JBS access you
can add comments directly to the issue, but please also comment here for the
benefit of those who cannot receive automated JBS updates.
Thanks to Raffaello for supplying
Hi Paul,
On Mon, Apr 30, 2018 at 2:03 PM, Paul Sandoz wrote:
>
>
> On Apr 30, 2018, at 11:18 AM, Martin Buchholz wrote:
>
>
>
> On Mon, Apr 30, 2018 at 10:35 AM, Paul Sandoz
> wrote:
>
>> An obvious optimization:
>>
>> 8202398: Optimize Arrays.deepHashCode
>> http://cr.openjdk.java.net/~martin
FYI here’s the javadoc for a draft of the Hex API that Alan mentioned below:
http://cr.openjdk.java.net/~vinnie/8170769/javadoc.05/api/java.base/java/util/Hex.html
Thanks.
> On 2 May 2018, at 10:55, Jonas Konrad wrote:
>
> I did not know about the old HexDumpEncoder. It extends an internal cla
Hi Martin,
Did you consider using Class::isArray in the loop? Something like the following:
for (Object element : a) {
final int elementHash;
if (element == null) {
elementHash = 0;
}
else {
final Class cl = element.getClass();
if (!cl.isArray())
elementHash = element.h
Michael, Thanks.
This may be tricky. isArray is a native method, and we don't want to pay
for native method overhead - we're depending on hotspot intrinsification.
I suspect isArray will lose with -Xint and perhaps also with C1. In the
hotspot sources I see an ominous
virtual bool is_array_klas
But getComponentType itself calls isArray, so you are paying the native method
overhead anyway (though it is intrinsic).
I haven't dug further into the JIT generated code to see why isArray performs
better though.
/Michael
From: Martin Buchholz
Sent: 03 May
On 4/30/18 5:49 AM, Claes Redestad wrote:
Hi,
please review this patch to enable caching of getCanonicalName and
getSimpleName, repeated calls of which has been reported to be a
performance
bottleneck. The caching improves performance of these methods by up to
20x.
Rather than adding new f
On Wed, May 2, 2018 at 2:43 PM, Michael Rasmussen <
michael.rasmus...@roguewave.com> wrote:
> But getComponentType itself calls isArray, so you are paying the native
> method overhead anyway (though it is intrinsic).
>
Ohhh, I had forgotten I had looked at getComponentType earlier. So
calling g
Hi,
Here is patch for 6443578 and 6202130 also in webrev form.
http://files.paratix.ch/jdk/6372077and6443578/webrev.01/
http://files.paratix.ch/jdk/6372077and6443578/webrev.01.zip
Hope it helps. With all the patience, can I do anything to make it
easier to get feedback or find a sponsor?
Reg
java/lang/String/nativeEncoding/StringPlatformChars.java
This test was problem listed due to execution environment issue
(-nativepath was not set) on Solaris and Windows platforms (JDK-8182569).
This is not an issue anymore, test PASS on all platform in CI system.
Please review the patch to r
Hi Philipp,
Thanks for your patience :-) I will get back to you with my feedback the
next couple days.
-Sherman
On 5/2/18, 6:12 PM, Philipp Kunz wrote:
Hi,
Here is patch for 6443578 and 6202130 also in webrev form.
http://files.paratix.ch/jdk/6372077and6443578/webrev.01/
http://files.parat
On 03/05/2018 06:16, Amy Lu wrote:
java/lang/String/nativeEncoding/StringPlatformChars.java
This test was problem listed due to execution environment issue
(-nativepath was not set) on Solaris and Windows platforms (JDK-8182569).
This is not an issue anymore, test PASS on all platform in CI
Philipp,
I kinda recalled JDK-6202130 which I read long time ago and I believed
it's not a bug but
just wanted to leave it open and for double check, then it's off the
priority list somehow...
Reread the code below I think it handles utf8 and the 72-length-limit
appropriately, though
a litt
23 matches
Mail list logo
