On Wed, 1 Sep 2021 06:45:26 GMT, Wu Yan wrote:
> Hi,
> Please help me review the change to enhance getting time zone ID from
> /etc/localtime on linux.
>
> We use `realpath` instead of `readlink` to obtain the link name of
> /etc/localtime, because `readlink` can only read the value of a symb
On Thu, 8 Jul 2021 00:45:48 GMT, Joe Darcy wrote:
> However, the bitwise conversion should now be fast everywhere.
Doesn't it require moves between general-purpose and floating-point registers?
Those have to go through memory for some targets (including old x86, where the
ISA supports it, but
On Fri, 12 Feb 2021 12:22:44 GMT, Vladimir Kempik wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435:
>>
>>> 433: //||\ Java thread created by VM does not
>>> have glibc
>>> 434: //|glibc guard page| - guard, attached Java thread usuall
* some-java-user:
> However, neither the static fields are `volatile` nor are the getter
> methods synchronized. So if my understanding of the Java Memory
> Model is correct, the compiler is free to reorder the two static
> field reads. So it is in theory possible that the first read yields
> a no
* David Holmes:
> More accurately soft-references will be cleared before throwing an OOME
> due to Java heap exhaustion. There are other things that can throw OOME
> (like your array example, or "throw new OutOfMemoryError();") that don't
> correspond to heap exhaustion and and so soft-referenc
* Peter Levart:
> But I see that the new IMM_LIST_NULLS type is needed for one other
> thing - the immutable list implementation of that type has different
> behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when
> null is passed to those methods) so this behavior has to be pre
On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks wrote:
> This change introduces a new terminal operation on Stream. This looks like a
> convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> method directly on
* Kim Barrett:
> And strlen is not even necessarily the best solution, as it likely
> introduces an additional otherwise unnecessary string traversal. For
> example, getFlags could be changed to reject an overly long ifname,
> without using strlen, thusly:
>
> strncpy(if2.ifr_name, ifname, siz
* Kim Barrett:
>> On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote:
>>
>> * Daniel Fuchs:
>>
>>> Hi,
>>>
>>> On 02/09/2020 08:19, Florian Weimer wrote:
>>>> At least one of the bugs was in theory user-visible: the network
>&
* Daniel Fuchs:
> Hi,
>
> On 02/09/2020 08:19, Florian Weimer wrote:
>> At least one of the bugs was in theory user-visible: the network
>> interface code would return data for an interface that does not actually
>> exist on the system.
>
> WRT NetworkInterface.
* Magnus Ihse Bursie:
> Maybe we should have a common library for all native code where we
> supply our own string operation functions? It will then be much easier
> to make sure the implementation passes different compiler versions,
> and that we provide sane semantics (which isn't really the c
* Сергей Цыпанов:
> Hi,
>
>> Isn't this InputStream::readAllBytes?
>
> thanks for pointing this out! Indeed, InputStream::readAllBytes() allows to
> save even more memory:
>
> Mode Cnt Score Error Units
> read avg
* Сергей Цыпанов:
> @@ -105,12 +105,8 @@
> private byte[] getBytes(InputStream is)
> throws IOException
> {
> -byte[] buffer = new byte[8192];
> ByteArrayOutputStream baos = new ByteArrayOutputStream(2048);
> -int n;
> -while ((n = is.read(buffer
* Florian Weimer:
> * Alan Bateman:
>
>> On 01/08/2020 10:23, Florian Weimer wrote:
>>> Are jdk.internal.ref.SoftCleanable and jdk.internal.ref.WeakCleanable
>>> actually used?
>>>
>>> CleanerTest rests them, but I don't see any other mention
* Remi Forax:
> I still don't like the fact that IntMapMultiConsumer,
> DoubleMapMultiConsumer and LongMapMultiConsumer are not in
> java.util.function unlike all other functional interfaces used by
> the Stream API.
They seem rather too specific for java.util.function to me. Maybe we
should add
* Patrick Concannon:
> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.05/
+ * The results of this method are undefined if the second {@link
IntConsumer}
+ * argument is operated on outside the scope of the mapper function.
Should this say “after the mapper functio
* Alan Bateman:
> On 01/08/2020 10:23, Florian Weimer wrote:
>> Are jdk.internal.ref.SoftCleanable and jdk.internal.ref.WeakCleanable
>> actually used?
>>
>> CleanerTest rests them, but I don't see any other mentions of these
>> classes.
> Do you mean u
Are jdk.internal.ref.SoftCleanable and jdk.internal.ref.WeakCleanable
actually used?
CleanerTest rests them, but I don't see any other mentions of these
classes.
* Justin Dekeyser:
> Nevertheless, the point was not really about list stuffs, and is not
> related to the lack of co/contra variance.
> You may replace List with any other generic class Foo and Integer
> and Number with any other class satisfying the same inheritance
> relations.
Ahh, well, but
* Justin Dekeyser:
> Then the following codes does not compile (for the same reason):
>
> var x = (List) emptyList(Number.class);
> List x = (List) emptyList(Number.class);
>
> incompatible types: List cannot be converted to List
>
> however, the following do compile:
>
> var x = emptyList(Number.
* Martin Buchholz:
> I wrote an earlier version of this grow logic, and then it was
> transplanted into other classes.
>
> We strongly suspect that the VM will throw OOME when we try to
> allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so,
> but we also consider the VM behavior a b
* Florian Weimer:
> * Mark Kralj-Taylor:
>
>> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
>> should be supported if the clock_gettime() API exists. But other clock
>> sources are not mandatory.
>
> Really old glibc emulates clock_
* Mark Kralj-Taylor:
> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
> should be supported if the clock_gettime() API exists. But other clock
> sources are not mandatory.
Really old glibc emulates clock_gettime (CLOCK_REALTIME) using
gettimeofday, yes.
clock_gettime was a
* Thomas Stüfe:
> Hi Tagir,
>
> nice work. Only a partwise review for TreeMap.java, did not yet look at the
> tests.
>
> remapValue:
>
> 711 } else {
> 712 // replace old mapping
> 713 t.value = newValue;
> 714 return newValue;
> 715 }
>
> S
* Magnus Ihse Bursie:
> On 2020-03-24 09:59, Andrew Dinn wrote:
>> On 23/03/2020 18:38, Erik Joelsson wrote:
>>> Looks good.
>> Thanks for the review, Erik.
>>
>> I'm assuming that also implies it is trivial (because, copyright update
>> a side, it really is a 1-liner :-).
>
> For code in the buil
* 向伟(识月):
> Hi Florian,
>
> This isn't a common usage.
> For the below code:
>
> String s1 = "s1".intern();
> f.set("s1".intern(), f.get("s2"));
>
> After calling reflection, the value of s1 is changed to "s2".
> In some special scenarios, the original jar file can't be modified. But the
> user
* 向伟(识月):
> We create a simple case to reproduce the issue:
>
> import java.lang.reflect.Field;
> import java.lang.reflect.Modifier;
> public class StringTableTest {
> public static void main(String[] args) throws Exception {
> Field f = String.class.getDeclaredField("value");
>
* Bob Vandette:
> CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8239791
For ELF (at least in the GNU incarnation), a change to the installed
jni.h is not required to make the symbols hidden; a hidden definition
would be sufficient for that. The declaration may however allow the
compiler to g
* Claes Redestad:
> we're doing plenty of iterations over Set.of() instances during
> bootstrap, which makes these operations show up prominently in
> startup profiles. This patch refactors a few hot methods to get a
> measureable startup improvement without regressing on targeted
> microbenchmark
* Andrew Haley:
> On 11/18/19 9:49 PM, Florian Weimer wrote:
>> I think the file should just be removed.
>>
>> Bug: <https://bugs.openjdk.java.net/browse/JDK-8234362>
>> Webrev: <http://cr.openjdk.java.net/~fweimer/8234362/webrev.01/>
>>
>> As
* Philipp Kunz:
> Hi,
>
> The Jar File Specification [1] states that,
>
>> Note: To prevent mangling of files sent via straight e-mail,
>> no header will start with the four letters "From".
>
> But I can't see that this is actually the case.
I think the problem are the five bytes "From " at the s
* Florian Weimer:
> * Florian Weimer:
>
>> __kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c
>> is built for _IEEE_LIBM targets as well, but it appears superfluous
>> there.
>>
>> In noticed this because GCC 10 flags an uninitialized v
* Maurizio Cimadamore:
> While this could be done (and it was considered early during the design
> phase), we decided against it for two reasons: first, the VarHandle API
> is very expressive and already supports. atomic compareAndSwap
> operations out of the box, which are _very_ handy when d
* Florian Weimer:
> __kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c
> is built for _IEEE_LIBM targets as well, but it appears superfluous
> there.
>
> In noticed this because GCC 10 flags an uninitialized variable in this
> code:
>
> …/src/java.bas
__kernel_standard in src/java.base/share/native/libfdlibm/k_standard.c
is built for _IEEE_LIBM targets as well, but it appears superfluous
there.
In noticed this because GCC 10 flags an uninitialized variable in this
code:
…/src/java.base/share/native/libfdlibm/k_standard.c: In function
'__j__ke
* Vicente Romero:
> Please review the draft of the CSR for Core-libs support for records at [1]
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8233436
I would have expected something regarding serialization in the
description of java.lang.Record.
Right now, it appears to
* Сергей Цыпанов:
> Hello,
>
> current implementation of e.g. String.toUpperCase() returns the object
> it was called on in case all code points are in upper case.
>
> E.g. this test
>
> @Test
> public void upperCase() {
> String str = "AZ";// English
> assert str == str.toUpp
* Adam Farley8:
> Four GPLv2 files in 8u seem to be missing the classpath exception from the
> copyright section.
>
> Requesting reviews and a sponsor.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227715
>
> Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/
All these files are no
* mark reinhold:
> 2019/3/25 5:24:37 -0700, Florian Weimer :
>> Are there any guidelines for formatting exception messages?
>>
>> In particular, I'm interested in the case when the exception message
>> is a (clipped) sentence. Is it supposed to start with a
* Milan Mimica:
> On Thu, 5 Sep 2019 at 18:59, Florian Weimer wrote:
>>
>> But I think in the UDP case, the client will retry. I think the total
>> timeout in the TCP case should equal the total timeout in the UDP case.
>> That's what I'm going to implement
* Milan Mimica:
> On Wed, 4 Sep 2019 at 20:32, Florian Weimer wrote:
>>
>> If you use the initial UDP timeout (one second, I think), the kernel
>> will not complete the TCP handshake if the initial SYN segment is lost
>> because the retransmit delay during the ha
* Pavel Rappo:
>> On 4 Sep 2019, at 18:54, Florian Weimer wrote:
>>
>> You should use a larger timeout than the initial UDP timeout,
>> though.
>
> Could you elaborate on that?
If you use the initial UDP timeout (one second, I think), the kernel
will not com
* Pavel Rappo:
>> On 4 Sep 2019, at 18:38, Florian Weimer wrote:
>>
>>
>>
>> Maybe I'm mistaken, but I think this:
>>
>> 692 Tcp(InetAddress server, int port, int timeout) throws IOException {
>> 693 sock = new Socket(server, p
* Pavel Rappo:
>> On 4 Sep 2019, at 17:35, Florian Weimer wrote:
>>
>> * Milan Mimica:
>>
>>> Continuing in a new thread with a RFR of my own:
>>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
>>
>> I would add a comment why the
* Milan Mimica:
> Continuing in a new thread with a RFR of my own:
> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/
I would add a comment why there's no explicit TCP connection timeout in
the code. I assume you rely on the TCP stack having its own timeout,
right? But I think it can be q
* Andrew John Hughes:
> On 24/06/2019 14:54, Florian Weimer wrote:
>> * Severin Gehwolf:
>>
>>> Could I please get reviews for this 8u only change? The JDK 8u build
>>> logic for launcher files includes linker version script files (a.k.a
>>> mapfil
* Severin Gehwolf:
> Could I please get reviews for this 8u only change? The JDK 8u build
> logic for launcher files includes linker version script files (a.k.a
> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> as local. When the symbol is not visible to the dynamic loader
* Thomas Stüfe:
> Hi Florian,
>
> Interesting, but in this case it is not posix_spawn, but plain
> fork(). The VM does this, the exec calls come from us, not the
> libc. See childproc.c .
Ah. Others have unearthed the genealogy. Thanks for that.
I wonder if in a Java context, things are slight
* Thomas Stüfe:
> Then I ran an strace over it and saw this:
>
> 5332 [pid 3911] execve("./sleep2", ["./sleep2"], [/* 78 vars */] ...>
>
> ..
> 5342 [pid 3911] <... execve res
* Martin Buchholz:
> Very big picture - if we want to banish stack overflows forever, we would
> need to migrate the industry to split runtime stacks, which would add a bit
> of runtime overhead to every native function call. No one is heroic enough
> to make progress towards that. Maybe develop
* Jiangli Zhou:
> Hi Florian,
>
> On Fri, May 24, 2019 at 2:46 AM Florian Weimer wrote:
>>
>> * Jiangli Zhou:
>>
>> > [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
>> > (contributed by Jeremy Manson)
>>
>> _d
* Jiangli Zhou:
> Hi Florian,
>
> Thanks for the feedback!
>
> On Fri, May 24, 2019 at 3:13 AM Florian Weimer wrote:
>>
>> * David Holmes:
>>
>> > My thoughts haven't really changed since 2015 - and sadly neither has
>> > there been a
* David Holmes:
> My thoughts haven't really changed since 2015 - and sadly neither has
> there been any change in glibc in that time. Nor, to my recollection,
> have there been any other reported issues with this.
The issue gets occasionally reported by people who use small stacks with
large ini
* Jiangli Zhou:
> [3] change: http://cr.openjdk.java.net/~jiangli/tls_size/webrev/
> (contributed by Jeremy Manson)
_dl_get_tls_static_info is an internal symbol (it carries a
GLIBC_PRIVATE symbol version). Its implementation can change at any
time. Please do not do this.
Thanks,
Florian
* Jim Laskey:
> Good point. To make sure I fully understand what you are stating,
>
> - The argument for having an instance method is reasonable to achieve
> "flowiness".
Right.
> - However, only one version is necessary or desired, that is, "public
> String formatted(Object... args)".
Yes, thi
* Jim Laskey:
> All discussion is valid. I agree the ambiguity is tricky, but can be
> resolved by using explicit locale.
>
> Example:
>
> "%s".formatted(Locale.getDefault(), Locale.JAPAN);
>
> This guarantees the "public String formatted(Locale l,
> Object... args)" form is chosen with the
* Jim Laskey:
> Please do a code review of the new String::formatted instance method. This
> method was originally introduced under the name "format"
> in conjunction with Raw String Literals. The method is being reintroduced in
> conjunction with Text Blocks and renamed to avoid method
> resolu
* Thomas Stüfe:
> Hi all,
>
> (old mail thread:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060139.html)
>
> May I please have your reviews and opinions for the following bug fix:
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8223777
> cr:
> http://cr.openjdk.java.net/
* Thomas Stüfe:
> Since we deal with many libc variants, not only glibc, fixing
> posix_spawn just in glibc may not be sufficient, at least not for a
> long time.
I think Solaris already has the required functionality, so it's not
entirely glibc-specific.
> But if you would fix glibc and give it
* Thomas Stüfe:
> Right now I am worried more about things I cannot determine yet. Where
> before we would wait for the pipe to get broken, now we have a read
> call on the parent side, a write call on the child side, which both
> must succeed. Could they fail sporadically, e.g. due to EINTR? I kn
* David Lloyd:
> Pipe communication isn't very costly AFAIK. The added complexity
> would be waiting for either a thing to appear on the pipe indicating
> success or else a waitpid/waitid+WNOHANG for exit code 127. But
> writing a thing to the pipe won't help determine if the subsequent
> exec s
* Thomas Stüfe:
> This is impossible to fix completely - see Martin's comment about the
> impossibility to foresee whether an exec() will succeed without actually
> exec()ing. But at least we can test the execute permissions on the
> jspawnhelper. Which this fix does. This fixes Ubuntu 16.4 (Now,
Are there any guidelines for formatting exception messages?
In particular, I'm interested in the case when the exception message
is a (clipped) sentence. Is it supposed to start with a capital
letter?
If the message refers to a parameter name, the spelling should reflect
the name exactly, of cou
* Jason Mehrens:
> The initial implementation was only optimized to call into
> String.compare if the arguments were string [1]. I proposed the
> current code a general form to catch java.nio.CharBuffer and any new
> JDK implementations of CharSequence + Comparable.
>
> Naively, I lean towards "-
* Joe Darcy:
> - sb.append(Stream.of(typeparms).map(Class::typeVarBounds).
> - collect(Collectors.joining(",", "<", ">")));
> + sb.append(Arrays.stream(typeparms)
> + .map(Class::typeVarBounds)
> + .collect(C
* David Holmes:
> This should really be being discussed on core-libs-dev.
Okay, moving the conversation.
>> diff -r 70a423caee44 src/share/native/com/sun/java/util/jar/pack/zip.cpp
>> --- a/src/share/native/com/sun/java/util/jar/pack/zip.cppTue Oct 09
>> 08:33:33 2018 +0100
>> +++ b/src/sha
* Smita Kamath:
> I'd like to contribute an optimization for GHASH Algorithm using AVX
> Instructions. I have tested this optimization on SKX x86_64 platform
> and it shows ~20-30% performance improvement for larger message sizes
> (for example 8k).
Performance improvement against what? The pure
* Stephen Colebourne:
> On Tue, 23 Oct 2018 at 09:44, Florian Weimer wrote:
>> * Stephen Colebourne:
>>
>> > No, the day-of-month and day-of-week would remain the same, as the
>> > time is relative to those dates.
>>
>> My expectation is that t
* Thomas Stüfe:
>> The main problem for vfork in application code is that you need to *all*
>> disable signals, even signals used by the implementation. If a signal
>> handler runs by accident while the vfork is active, memory corruption is
>> practically guaranteed. The only way to disable the
* Stephen Colebourne:
> No, the day-of-month and day-of-week would remain the same, as the
> time is relative to those dates.
My expectation is that the values returned by the other methods would
change for a getLocalTime() that provides a normalized return value
because the transition rule in no
* Stephen Colebourne:
> Fixing the parser to handle values like 25:00 would be relatively
> easy. However, these rules are also exposed in the public API of
> java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has
> methods `getLocalTime()` and `isMidnightEndOfDay()`. These would ne
* Thomas Stüfe:
> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now - apart from it being obsolete. If you
> read my initial thread from September, you know that I think we have
> understood vfork's shortcomings very well, and that our (SAPs)
> p
* David Lloyd:
> Sure, but I don't really see this as necessary if glibc is already
> following the vfork-like path. Another thing to know is that at least
> in the 2.26 sources I have checked out, the POSIX_SPAWN_USEVFORK flag
> is completely ignored. See also [2].
Right, the manual pages are
On 07/06/2018 02:23 PM, Nasser Ebrahim wrote:
Hi Florian,
Thank you for your response. iconv is platform dependent and not good for
the platform agnostic nature of Java. Also, many charsets in Java are not
available across platforms. I believe Java decided to have its own
charsets due to those r
* Andrew Dinn:
>> +// TODO - remove the following defines
>> +// for testing we need to define the extra MAP_XXX flags used for
>> +// persistent memory. they will eventually get defined by the
>> +// system and included via sys/mman.h
>>
>> Do you really want to change implementa
* Paul Sandoz:
> I created this issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8208362
Thanks.
> The suggested fix requires a tweak though since an instance of a
> DirectBuffer interface is passed. This is required because views
> over direct ByteBuffers can be created.
Noticed that as w
* Andrew Dinn:
> Comments and suggestions for improvement would be very welcome.
There are a bunch of typos in the JEP (“susbet”, “Rntime”).
Formatting of the headlines looks wrong to me, too.
On the implementation side, I find this a bit concerning:
+// TODO - remove the following defines
src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
contains this, unfortunately without further comments:
| public $Type$Buffer slice() {
| int pos = this.position();
| int lim = this.limit();
| assert (pos <= lim);
| int rem = (pos <= lim ? lim
On 07/04/2018 02:41 PM, Nasser Ebrahim wrote:
Please share your thoughts on your preferred option and list out any other
options which I missed out. Thank you for your time.
Could you use the platform iconv implementation instead? That would
avoid shipping the tables in the JDK.
Thanks,
Flo
* Tony Printezis:
> There are a few obvious ways to mitigate this, e.g., cause a Full GC /
> concurrent GC cycle at regular intervals. However, the best solution IMHO
> is to explicitly free any direct buffers that are still in the cache when a
> thread exits.
Why is this safe? Couldn't these di
* John Rose:
> In https://bugs.openjdk.java.net/browse/JDK-8161256 I discuss
> this nascent API under the name "ByteSequence", which is analogous
> to CharSequence, but doesn't mention the types 'char' or 'String'.
Very interesting.
What's the specification for toString() and hashCode()?
One pr
Lately I've been thinking about string representation. The world
turned out not to be UCS-2 or UTF-16, after all, and we often have to
deal with strings generally encoded as ASCII or UTF-8, but we aren't
always encoded this way (and there might not even be a charset
declaration, see the ELF spec).
* Roger Riggs:
> Updated in place.
> http://cr.openjdk.java.net/~rriggs/webrev-net-cleanup-8195059/
Doesn't this leak the file descriptor of SocketCleanable.register
throws?
* Peter Levart:
> Simply saying that "vm is in a more critical status than a inflater is
> getting leaked out" is, in my opinion, covering the problem under the
> rug. The VM is not in critical state - the program is. VM is robust
> enough to recover from OOMEs. The program might be in critical
* Xueming Shen:
> It might be possible to try-catch to expect Cleaner.register might
> fail, but I doubt it's really necessary here and it is the
> recommended usage of Cleaner?
That is actually why I posted this. 8-)
For similar functionality in other languages, it is often necessary to
perform
* Xueming Shen:
> I removed the ln#657-#663, and updated the @apiNote in deflter, inflater
> and zipfile accordingly, mainly combined your comment and the approach
> for the fis/fo. they are "simpler" and straightforward now, at least for me.
>
> https://bugs.openjdk.java.net/browse/JDK-8187485
>
check could not
be added to the JDK.
--
Florian Weimer / Red Hat Product Security
weight?
Feeding program arguments to command spawned by a shell is difficult.
There is also no good way to obtain the exit status of the first command
in the pipe. The last command in the pipe determines the shell exit
status, and earlier commands are ignored.
--
Florian Weimer / Red Hat Product Security
l of the
collection may fail with an exception for self-referential instances
where the collection directly or indirectly contains itself. This
includes the clone(), equals(), hashCode() and toString() methods.
Implementations may optionally handle the self-referential scenario,
however most current implemen
cation of any file.
--
Florian Weimer / Red Hat Product Security
On 02/27/2015 06:16 PM, Paul Sandoz wrote:
> On Feb 27, 2015, at 4:47 PM, Florian Weimer wrote:
>> I really don't think this tooling support will provide sufficient
>> enticement to developers to maintain separate 7/8/9 source branches of
>> their libraries. Isn't
On 02/27/2015 03:20 PM, Alan Bateman wrote:
> On 27/02/2015 13:27, Florian Weimer wrote:
>> :
>> I'm wondering how you propose to build such JAR files. Do you think
>> library developers will maintain two separate branches, compile one with
>> JDK 8, the other o
h JDK 9, and then use some (not yet existing?)
tool to merge the output into a single JAR? Is such automated merging
even possible if the bytecode was compiled with different javac versions?
What about presenting Javadoc in a useful fashion?
--
Florian Weimer / Red Hat Product Security
allocations, you should use the destination
buffer passed to the read() function if the slice end is equal to the
array end. I expect that this is the usual case.
By the way, I think such review requests should be sent to security-dev,
not core-libs-dev.
--
Florian Weimer / Red Hat Product Security
kMult(subkeyH0, subkeyH1);
181 }
That is, the byte array is supplied by the caller, and if we wanted to
use a ByteBuffer, we would have to allocate a fresh one on every
iteration. In this case, neither of the two alternatives you list apply.
--
Florian Weimer / Red Hat Product Security
On 02/17/2015 11:00 AM, Andrew Haley wrote:
> On 02/17/2015 09:39 AM, Florian Weimer wrote:
>> On 02/14/2015 01:09 AM, John Rose wrote:
>>> These queries need to go into Unsafe.
>>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
>>>
gned accesses? Then new ports will see the failure
immediately and can tweak the code.
--
Florian Weimer / Red Hat Product Security
e JDK has quite a few uses for them (particularly the big
endian variant). Putting that into Unsafe only encourages further use
of Unsafe from application code.
--
Florian Weimer / Red Hat Product Security
rease resiliency of the test suite. From that perspective, throwing
UnsupportedOperationException is better than just silently doing nothing.
--
Florian Weimer / Red Hat Product Security
On 08/20/2014 06:43 PM, Andrew Haley wrote:
> On 08/20/2014 04:10 PM, Florian Weimer wrote:
>> Is there already a way to compute the expression in the subject without
>> the ByteBuffer allocation? I saw quite a few equivalent formulations in
>> the OpenJDK sources, and per
1 - 100 of 228 matches
Mail list logo
