In retrospect I don't know why I expected Math.multiplyHigh() to
return the high word of the unsigned product of two 64-bit numbers,
given that long is signed; in my defence however, the docs don't
actually seem to specify.
WDYT about a patch like this to clarify?
diff --git a/src/java.base/share
I'm helping a colleague debug a weird problem that occurs in
ClassValue on jdk11u (and presumably on upstream as well, though it's
presently impossible to verify). As a disclaimer, the problem
manifests itself when building native images via GraalVM so it's
possible that something is simply broken
In this case, going from what the execve(2) Linux man page says (and Mac
seems to agree), if the script were executable it would have a '#!'
interpreter string and the kernel would execute it anyway, would it not?
What case would be solved by explicitly starting a shell?
On Tue, Jun 4, 2019 at 2:1
er to deal with this - look at how long simple fixes are in
>> review, we are all busy elsewhere - chances of changing this are small.
>>
>> Cheers, Thomas
>>
>>
>> On Tue, Jun 4, 2019 at 10:14 PM David Lloyd
>> wrote:
>>
>>> In this case,
https://www.unix.com/man-page/redhat/2/execve/ is from 1997.
On Wed, Jun 5, 2019 at 9:50 AM David Lloyd wrote:
> If we're talking just Linux though, has this *ever* been an issue? You've
> been able to call execve on a shell script since at least 2002 as far as I
> can tell
On Tue, Jul 9, 2019 at 8:19 AM Jaikiran Pai wrote:
> - In addition, I have sneaked in an unrelated change in this patch, into
> the Deflater.end() method:
>
> public void end() {
> synchronized (zsRef) {
> +// check if already closed
> +if (zsRef.address() ==
On Sat, Sep 28, 2019 at 3:39 AM Peter Levart wrote:
>
> On 9/25/19 12:15 PM, Remi Forax wrote:
> > that said, i believe we should deprecate LinkedList (and any other List
> > implementation that doesn't implement RandomAccess) because there are too
> > much code out there that suppose that list.
On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman wrote:
>
> On 18/11/2019 15:01, Jaikiran Pai wrote:
> > :
> >
> > So this Class-Path entry is being ignored starting Java 13.
> >
> Yes, bad values are now ignored, bringing an end to an effort on the
> run-time over multiple releases to fix the problem
On Mon, Nov 18, 2019 at 9:37 AM Alan Bateman wrote:
>
> On 18/11/2019 15:01, Jaikiran Pai wrote:
> > :
> >
> > So this Class-Path entry is being ignored starting Java 13.
> >
> Yes, bad values are now ignored, bringing an end to an effort on the
> run-time over multiple releases to fix the problem
On Wed, Nov 20, 2019 at 2:25 AM Alan Bateman wrote:
>
> On 19/11/2019 23:25, David Lloyd wrote:
> > :
> > OK, having read the updated specification (thanks Alan!) I'm now quite
> > curious why `/C:/helloworld.jar` is considered invalid. It is in fact
> > a val
On Wed, Nov 20, 2019 at 9:26 AM Scott Palmer wrote:
>
> /C:/blah... is “root relative”. The (old) spec says the URL must be "relative
> to the code base". What does "code base" mean when not referring to Applets
> or RMI?
"code base" is generally the URL of the class path entry itself. It's
m
On Wed, Nov 20, 2019 at 8:59 AM Alan Bateman wrote:
>
> On 20/11/2019 13:50, David Lloyd wrote:
> > :
> > OK, but this decision violates both the old and updated spec (and
> > makes it difficult to write code that works in both cases: in
> > situations that rejec
On Mon, Nov 25, 2019 at 11:28 AM wrote:
>
> https://openjdk.java.net/jeps/370
Looks pretty interesting! Why make the API user deal with VarHandles
though, as opposed to (say) putting accessor methods directly onto
MemoryAddress?
--
- DML
On Mon, Nov 25, 2019 at 11:28 AM wrote:
>
> https://openjdk.java.net/jeps/370
One more question! Well, two I guess.
First, in the interim before Panama or something like it comes to the
main project, will it be possible to pass MemoryAddress kinds of
things to JNI methods (to replace the curren
On Thu, Nov 28, 2019 at 11:24 AM Vladimir Ivanov
wrote:
>
>
> >> Second, what about an API to allocate memory from the stack? This is
> >> really useful in GraalVM (granted they have a sort-of-Panama-ish way
> >> of calling C functions already, and they're really quite "loose" when
> >> it comes
On Fri, Nov 29, 2019 at 5:34 PM John Rose wrote:
>
> On Nov 29, 2019, at 4:24 AM, David Lloyd wrote:
>
>
> Makes sense, it's still early. But now the seed is planted. :)
>
>
> (It’s better documented. Most of the points made here were not new.)
Okay, anyway I&
On Fri, Jan 24, 2020 at 4:56 PM David Holmes wrote:
>
> FYI.
I'm a bit curious about this:
> To invoke private nestmate instance methods from code in the hidden class,
> use invokevirtual or invokeinterface instead of invokespecial. Generated
> bytecode that uses invokespecial to invoke a priv
On Mon, Jan 27, 2020 at 12:30 PM Mandy Chung wrote:
>
>
>
> On 1/27/20 6:31 AM, Remi Forax wrote:
>
> I'm a bit curious about this:
>
> To invoke private nestmate instance methods from code in the hidden class, use
> invokevirtual or invokeinterface instead of invokespecial. Generated bytecode
> t
On Wed, May 19, 2021 at 4:01 AM Andrew Haley wrote:
> On 5/15/21 6:50 PM, Peter Levart wrote:
> > What if I wanted to create and start a thread that would be "pristine" -
> > not have any ScopeLocal value bound? Is this intentionally not allowed
> > in order to make sure that inheritable ScopeLoc
On Wed, May 12, 2021 at 9:43 AM Andrew Haley wrote:
> There's been considerable discussion about scope locals on the loom-dev
> list,
> and it's now time to open this to a wider audience. This subject is
> important
> because. although scope locals were motivated by the the needs of Loom,
> they
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
wrote:
> 1. Develop authorization layer security provider services in OpenJDK,
> back port it to Java 8 and Java 11 (these provide most of the
> utilised functionality of SecurityManager, allowing developers to
> only implement those whi
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
> SecurityManager depends on Permission, currently there are Permission
> checks throughout the JVM, however Permission implementation classes
> will be removed, although the Permission class itself won't be.
This is incorrect AFAICT. The re
Is this better than the current solution of `nativeOrder() ==
BIG_ENDIAN` other than reducing a few keystrokes?
On Fri, Jun 25, 2021 at 8:45 AM Yi Yang wrote:
>
> Hi, can I have a review of this change that adds two new utility methods for
> java.nio.ByteOrder? Looking through the whole JDK code
On Mon, Apr 25, 2022 at 8:09 AM wrote:
> because it would still run finally blocks, which cannot happen for no return
> methods like System.exit and Runtime.halt
FWIW I don't think this is correct. `exit` and `halt` etc. cannot
*return* but they're definitely allowed to throw an exception
(`Secu
On Mon, Apr 25, 2022 at 9:25 AM wrote:
>
> Ok, you're right that it can raise an exception when the calling thread does
> not have the security privileges needed. But what if it had them ? Right now
> the deadlock comes from the fact is doesn't got back to the caller with an
> exception and doe
Can they be method refs, or is this one of those cases where it could
be early boot where none of that stuff works yet?
--
- DML
> On Mar 4, 2016, at 10:19 AM, Roger Riggs wrote:
>
> Hi Daniel,
>
> Good idea.
>
> SimpleConsolerLogger.java:
> Some of the property accesses could use the existing
On Wed, Oct 3, 2018 at 7:53 PM Sergey Bylokhov
wrote:
> Hi, Sean.
> One question related to SecurityManager and performance, is it possible
> to provide a special version of AccessController.doPrivileged which will
> be noop if SecurityManager is not present?
TBH that method (at least, the no-arg
The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process
launching on Linux, but it's the closest I could find out of what are
really a surprisingly large number of issues that refer to posix_spawn
in one way or another relating to ProcessImpl. There's a different
issue to move from vfork
On Fri, Oct 19, 2018 at 1:56 AM Thomas Stüfe wrote:
>
> Hi David,
>
> (for convenience, here the old thread:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html)
>
> I would rather not expose a third way to spawn to the end user. As a
> test switch for developers, thi
On Sun, Oct 21, 2018 at 7:25 PM Martin Buchholz wrote:
> As author of the vfork strategy ... I'm supportive of the directions in this
> thread.
Great.
> vfork is even (!) less in favor than it used to be, so migrating off of it
> seems good. Just make sure we don't bring back the OOM problem
On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe wrote:
> Hi all,
[...]
> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now
Note that my patch does not abandon vfork. It does not even change
the default exec strategy away from vfork, nor does it ca
I've submitted a bug report via bugreport.java.com. If/when it gets
promoted to a proper JIRA with an issue number, I'll see if I can put
the patch up on jdk/submit.
On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote:
>
> The issue 6850720 isn't _exactly_ to use PO
bug report on JBS for you. Should I?
>
> (Now I understand the "reuse bug id").
>
>
> On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote:
> >
> > I've submitted a bug report via bugreport.java.com. If/when it gets
> > promoted to a proper JIRA with an
;
> Here you go:
>
> https://bugs.openjdk.java.net/browse/JDK-8212828
>
> If noone else steps in, I can sponsor the change for you.
>
> Cheers, Thomas
> On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote:
> >
> > Sure. I don't have any tracking information on
David, et.al.
>
> What would be the rest of the plan for testing?
> Usually, changes come with tests and a plan.
> What build parameters are needed to run a full set of tests with the change?
>
> Are there build changes needed?
>
> Thanks, Roger
>
>
> On 10/23/
On Wed, Oct 24, 2018 at 1:05 AM Thomas Stüfe wrote:
> Review:
>
> - copyright dates need updating on the C-sources
>
> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) ||
> defined(_AIX) || defined(__linux__)" to be removed completely from
> unix-specific source files. The ifdef no
On Wed, Oct 24, 2018 at 8:52 AM Thomas Stüfe wrote:
>
> Hi David,
>
> I think we need some form of test, as Alan indicated.
>
> java/lang/ProcessBuilder/Basic.java should run through. Actually, I
> would like it if we would run this test for all valid enabled launch
> mechanisms, regardless which
;> About the test: I added a new line:
> >>
> >>* @run main/othervm/timeout=300 Basic
> >>* @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork
> >> Basic
> >> + * @run main/othervm/timeout=300
> >> -Djdk.lang.Process.launchMechanism=posi
I'm in favor FWIW.
On Wed, Nov 28, 2018 at 9:36 AM Thomas Stüfe wrote:
>
> Hi all,
>
> I would like to have this patch in 11u too, so I just did a 11u
> downport request.
>
> Our agreement was that launchMechanism=POSIX_SPAWN would stay as
> optional non-default value for jdk12, and at the start o
Is vfork still guaranteed to be functional by the end of the Java 11
support frame, from the perspective of any organization which supports
JDKs of this version?
On Fri, Mar 8, 2019 at 9:22 AM Andrew Haley wrote:
>
> On 3/8/19 2:39 PM, Langer, Christoph wrote:
> > please review the CSR backport
On Sat, May 11, 2019 at 9:49 AM Remi Forax wrote:
>
> I've seen a weird error on my CI [1] since the 15th of February when using
> the jdk 13,
> i was not able to run jshell* using the programmatic API (java tool) anymore.
>
> Yesterday, i took the time to track that issue and i believe i've foun
On Mon, May 13, 2019 at 11:01 AM Thomas Stüfe wrote:
>
> Hi all,
>
> may I have please your opinions about the following change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223777
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8223777-posix_spawn-no-exec-error/webrev.00/webrev/
> [.
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 succeeded, which is really
Ah I see. I like the idea, it would mean pretty comprehensive error
reporting and should work across platforms too I think.
On Tue, May 14, 2019 at 7:16 AM Florian Weimer wrote:
>
> * David Lloyd:
>
> > Pipe communication isn't very costly AFAIK. The added complexity
>
I'm in favor of what the change is meant to accomplish. I haven't had
time to analyze the change in detail, and I may not get time to do so.
But I'm not a reviewer in any case, so maybe that doesn't matter too
much.
On Wed, May 22, 2019 at 1:16 AM Thomas Stüfe wrote:
>
> Ping...
>
> Guys, I need
Yes! It would be even better for the "toArray(Class)" case if
Class had a "getArrayClass()" method which returned the Class,
which would allow:
return (T[]) Arrays.copyOf(elementData, size, componentType.getArrayClass());
and similar for other array-backed collections. I never understood
why
I was doing some research related to AccessController, and I noted
this code [1] in StackFrameInfo#getByteCodeIndex():
@Override
public int getByteCodeIndex() {
// bci not available for native methods
if (isNativeMethod())
return -1;
return bci;
}
Now bci is of type short, an
On Fri, Dec 8, 2017 at 12:38 PM, Brian Burkhalter
wrote:
> Patrick’s comment made us think again about the naming here as “nullStream()”
> would not fit for eventual equivalent methods on Reader and Writer. It might
> be better to go with something like
>
> InputStream InputStream.nullSource();
On Fri, Dec 8, 2017 at 1:03 PM, Brian Burkhalter
wrote:
> On Dec 8, 2017, at 10:52 AM, David Lloyd wrote:
>
>> On Fri, Dec 8, 2017 at 12:38 PM, Brian Burkhalter
>> wrote:
>>> Patrick’s comment made us think again about the naming here as
>>> “nullStream()” w
kFrameInfo.java
> @@ -93,7 +93,7 @@
> if (isNativeMethod())
> return -1;
>
> -return bci;
> +return bci & 0x;
> }
>
> Mandy
>
> On 12/7/17 8:19 PM, David Lloyd wrote:
>
> I was doing some research related to Acces
On Mon, Dec 11, 2017 at 9:03 PM, mandy chung wrote:
> On 12/11/17 6:31 PM, Martin Buchholz wrote:
>> Java has an unsigned 16 bit type. Could bci be of type "char" ?
>
> Yes but I think keeping it short is fine.
Call me strange if you like, but I never liked using char as anything
other than a UT
On Mon, Dec 11, 2017 at 8:00 PM, John Rose wrote:
> I submit to you that such a factory is *not* an IntFunction, because
> that only creates half of an array (or 0.01% of one), the empty
> version that needs to be populated. A natural array factory API
> [...]
> The interface would look something
I'm not a reviewer, but I was curious about this change; unfortunately
the diff seems to be dominated by case and formatting changes making
the actual functional aspect change hard to divine.
Within the JBoss unit we have an informal policy that formatting
changes should be presented separately so
On Thu, Dec 21, 2017 at 6:35 PM, David Holmes wrote:
> I believe there are concerns with too much information that can be
> considered "sensitive" (like host names and IP addresses) appearing in error
> messages due to them ending up in log files and bug reports.
I tend to agree here. However -
On Fri, Dec 29, 2017 at 11:15 AM, Chris Hegarty
wrote:
> On 29 Dec 2017, at 00:33, Steven Schlansker
> wrote:
>> Thanks for the discussion!
>>
>> So, it sounds like amending the message by default is going to be a
>> non-starter -- but at least adding the information otherwise might be
>> poss
On Tue, Feb 13, 2018 at 2:41 AM, Alan Bateman wrote:
> On 13/02/2018 06:24, Xueming Shen wrote:
>>
>> Hi,
>>
>> Please help review the proposal to add following constructors and methods
>> in String
>> class to take ByteBuffer as the input and output data buffer.
>>
>> public String(ByteBuffer byt
It would be convenient to be able to inflate/deflate a direct or heap
byte buffer without having to copy it through an array first. For my
Friday mini-project this week, I've decided to take a crack at this.
The attached patch is the result. Would anyone be interested in
reviewing and maybe spons
Also available in more readable form at:
https://github.com/dmlloyd/openjdk/commit/becd36e852e55a29a4685577453944552c817b66
On Fri, Feb 16, 2018 at 4:13 PM, David Lloyd wrote:
> It would be convenient to be able to inflate/deflate a direct or heap
> byte buffer without having to c
On Sat, Feb 17, 2018 at 3:18 PM, Xueming Shen wrote:
> Hi David,
>
> Thanks for taking this one :-) some comments here.
Thanks for the review!
> (1) I would assume you might have to do more for ByteBuffer, something like
> [...]
> btw, any reason go unsafe to get the byte[]? instead of
> Byt
On Sun, Feb 18, 2018 at 3:33 AM, Alan Bateman wrote:
> Thanks for bringing this one up again
Thanks for taking the time to review.
> I see Sherman is looking at implementation so I'll stick with the javadoc
> for now. At some point it will need a security review to ensure that there
> no possibi
I agree with Uwe and Remi; if the default is still changeable, the
problem doesn't go away, it simply becomes slightly more insidious.
On Wed, Feb 21, 2018 at 12:31 AM, Xueming Shen wrote:
> This draft JEP contains a proposal to use UTF-8 as the default charset for
> the JVM, so that
> APIs that
This is the second version of the patch first discussed here [1] to
add the ability to inflate/deflate to/from heap/direct byte buffers.
The patch is attached, as well as benchmark results with the original
and new code, and the benchmark source. The patch is also visible
online at [2].
Some not
The third... and hopefully final... version of this patch is attached.
It is the same as V2, however it also uses
Reference.reachabilityFence() defensively on buffers. This may be
necessary because there are code paths which may allow such buffers to
be GCed after their address is acquired but bef
On Fri, Mar 2, 2018 at 12:49 PM, Xueming Shen wrote:
> Hi David,
>
> (1) Deflater.deflate(Bytebuffer)
> the api doc regarding "no_flush" appears to be the copy/paste of the
> byte[] version
> without being updated to the corresponding ByteBuffer?
You're right, I missed that one. I've i
On Fri, Mar 2, 2018 at 2:34 PM, David Lloyd wrote:
> On Fri, Mar 2, 2018 at 12:49 PM, Xueming Shen wrote:
>> Hi David,
>>
>> (1) Deflater.deflate(Bytebuffer)
>> the api doc regarding "no_flush" appears to be the copy/paste of the
>> byte[] v
The fourth version of this patch is attached. There is one functional
change; the rest are documentation changes.
The functional change is that Inflater now updates both the input and
output buffer position, as well as the produced/consumed byte count
and remaining count, in the event of a DataFo
18 at 2:36 PM, David Lloyd wrote:
> On Fri, Mar 2, 2018 at 2:34 PM, David Lloyd wrote:
>> On Fri, Mar 2, 2018 at 12:49 PM, Xueming Shen
>> wrote:
>>> Hi David,
>>>
>>> (1) Deflater.deflate(Bytebuffer)
>>> the api doc regarding "no_
I worked up a little patch for 8188240. I was able to co-opt an
existing test which now fails before the patch and passes after. It's
a tiny patch so I'm including it inline. I've CC'd Mandy because she
filed the original bug.
Here's the patch (use patch -p1 to apply):
cut --- 8<
On Tue, Mar 13, 2018 at 6:31 PM, mandy chung wrote:
> I prefer to keep the original test case i.e. create a proxy class from
> Runnable and Observer. Instead add a new test case to create a proxy class
> with ClashWithRunnable, Runnable and Observer and verify that it does not
> include static m
On Tue, Mar 13, 2018 at 7:16 PM, David Lloyd wrote:
> On Tue, Mar 13, 2018 at 6:31 PM, mandy chung wrote:
>> I prefer to keep the original test case i.e. create a proxy class from
>> Runnable and Observer. Instead add a new test case to create a proxy class
>> with ClashW
In:
@@ -196,14 +194,32 @@
return len;
}
+public synchronized byte[] readAllBytes() {
+byte[] result = Arrays.copyOfRange(buf, pos, count);
+pos = count;
+return result;
+}
+
+public synchronized int readNBytes(byte[] b, int off, int len) {
+
On Wed, Mar 14, 2018 at 1:00 PM, mandy chung wrote:
> Thanks for adding the new test. Looks okay and some minor comment.
>
> +try {
>:
> +} catch (Throwable e) {
> +System.err.println("\nTEST FAILED:");
> +e.printStackTrace();
> +throw new
On Wed, Mar 14, 2018 at 4:31 PM, Aleksey Shipilev wrote:
> On 03/14/2018 07:09 PM, David Lloyd wrote:
>> On Wed, Mar 14, 2018 at 1:00 PM, mandy chung wrote:
>>> Thanks for adding the new test. Looks okay and some minor comment.
>>>
>>> +try {
>&g
output ByteBuffer when DFE
> raised (in Java), but
> the corresponding "byteWritten" is not being updated before the
> exception is thrown.
>
> -Sherman
>
>
>
>
> On 3/13/18, 10:46 AM, David Lloyd wrote:
>>
>> Sorry all, it looks like GMail d
Since adding a field called "name" to java.lang.ClassLoader, the
"name" anchor which previously referred to the section entitled
"binary names" has been broken.
The attached doc-only patch changes the name of the anchor to
"binary-name". It applies with "patch -p1".
--
- DML
diff --git a/src/ja
I discovered there are a couple of references outside of ClassLoader
as well. Here's the updated patch...
On Wed, Mar 21, 2018 at 10:58 AM, David Lloyd wrote:
> Since adding a field called "name" to java.lang.ClassLoader, the
> "name" anchor which previously r
otherwise change nothing.
> I'm confused by the subject. There is no such bug
I submitted it via bugreport.java.com; it hasn't been reviewed yet. I
expect it might show up soon.
> On Wed, Mar 21, 2018 at 9:03 AM David Lloyd wrote:
>>
>> I discovered there are
Ah, so the submitted bug ID doesn't match the final bug ID. Excellent.
On Wed, Mar 21, 2018 at 11:24 AM, Martin Buchholz wrote:
> Found it.
> https://bugs.openjdk.java.net/browse/JDK-8199947
>
--
- DML
On Wed, Mar 21, 2018 at 12:04 PM, mandy chung wrote:
>
>
> On 3/21/18 8:58 AM, David Lloyd wrote:
>
> Since adding a field called "name" to java.lang.ClassLoader, the
> "name" anchor which previously referred to the section entitled
> "binary nam
Sorry. This looks OK to me (non-reviewer) now.
On Wed, Mar 21, 2018 at 1:01 PM, Brian Burkhalter
wrote:
> This is still in need of final approval, assuming it is OK.
>
> Thanks,
>
> Brian
>
> On Mar 14, 2018, at 10:50 AM, Brian Burkhalter
> wrote:
>
> On Mar 14,
On Wed, Mar 21, 2018 at 3:39 PM, mandy chung wrote:
> On 3/21/18 10:26 AM, David Lloyd wrote:
>
> I see it with IntelliJ IDEA when I pop up "quick JavaDoc" on, say,
> defineClass and then click on "binary name"; it's actually using the
> sources, rath
Are there any further comments on this? If not, would it be possible
to get a sponsor for this change?
Sorry again for the detached email threads; I've learned my GMail lesson well...
Thanks.
On Fri, Mar 16, 2018 at 8:25 AM, David Lloyd wrote:
> Sorry, that was an error on my part, c
On Fri, Mar 23, 2018 at 12:51 PM, Xueming Shen wrote:
>
> Hi David,
>
> Sorry for the late response. I will sponsor this change. Will prepare for
> the CSR for
> the new APIs.
Thanks!
> Couple more comments
>
> (1) Deflater.java/deflate(ByteBuffer, int);
> "In the case of FULL_FLUSH or SYNC_FLUS
On Fri, Mar 23, 2018 at 1:06 PM, Alan Bateman wrote:
> Is there an up to date webrev on cr.openjdk.java.net that we can review?
I'm an outside contributor so I don't have any easy way to prepare
one; however, if you wish, you can look at the diff on my GitHub
mirror here [1]. In case you're curi
On Mon, Mar 26, 2018 at 9:53 AM, Alan Bateman wrote:
> On 23/03/2018 19:17, David Lloyd wrote:
>>
>> All fixed. You're right, the catch blocks consolidated fairly easily
>> and it looks better. I've attached the latest version of the patch.
>>
> I w
On Tue, Mar 27, 2018 at 10:10 AM, Alan Bateman wrote:
> On 27/03/2018 00:09, David Lloyd wrote:
>> I was going for some kind of consistency with the array variants (that
>> is, name the parameter what it is), though they simply use "b" for
>> their parameter name so
On Tue, Mar 27, 2018 at 11:59 AM, David Lloyd wrote:
> On Tue, Mar 27, 2018 at 10:10 AM, Alan Bateman
> wrote:
>> On 27/03/2018 00:09, David Lloyd wrote:
>>> I was going for some kind of consistency with the array variants (that
>>> is, name the parameter what it
On Wed, Mar 28, 2018 at 11:38 PM, Xueming Shen wrote:
> On 3/28/18, 6:14 AM, David Lloyd wrote:
>> I've implemented all the other changes except for this one. Latest
>> version is attached, online version is here [1].
>
> "flush marker" was copy/pasted fro
Thanks!
On Fri, Mar 30, 2018 at 11:52 AM, Xueming Shen wrote:
> On 3/30/18, 7:07 AM, Alan Bateman wrote:
>>
>> On 29/03/2018 13:18, David Lloyd wrote:
>>>
>>> :
>>> OK great. In that case, I think all feedback has been accounted for,
>>> and
On Fri, Mar 30, 2018 at 12:05 PM, Xueming Shen wrote:
>
> Hi David,
>
> (1) Deflater.setDictionary(ByteBuffer) missed a "@since 11"
Oops, easy fix.
> (2) infalte(...) may not need to catch DFE twice, better (?) to just update
> the inputPos/input
> at outsider catch as
>
> if (input =
Is there anyone who would be willing to sponsor this change?
On Tue, Jan 23, 2018 at 4:58 PM, Jan Kalina wrote:
> Hi,
> I has prepared trivial patch for bug JDK-8176553, which I has reported.
>
> I will welcome if it could be merged into JDK.
> (The bug is present in JDK9 and JDK8 too.)
> I am co
Actually I've talked to Jan and we're going to try again with the more
correct subject line & RFR. Thanks.
On Wed, Apr 4, 2018 at 8:51 AM, David Lloyd wrote:
> Is there anyone who would be willing to sponsor this change?
>
> On Tue, Jan 23, 2018 at 4:58 PM, Jan Kalina
On Thu, Apr 5, 2018 at 4:45 PM, Tony Printezis wrote:
> Would proposing to introduce thread exit hooks be reasonable? Or is
> everyone going to freak out? :-) The hooks can be either per-Thread or even
> per-ThreadLocal. And it's OK if the hooks can only be used within java.base.
User-accessible
On Fri, Apr 6, 2018 at 8:57 AM, Tony Printezis wrote:
>> ThreadLocal clearing
>
> Could you clarify what you mean by ThreadLocal clearing?
I mean calling ThreadLocal#remove().
> I like the suggestion to add an overridable exit() method to ThreadLocal. If
> you want to avoid calling user code by
That's great news, thanks! I'll pull down your updates just so my
local copy does not get out of date in the meantime.
On Tue, Apr 10, 2018 at 10:49 PM, Xueming Shen wrote:
> Hi David,
>
> The CSR has been approved
> https://bugs.openjdk.java.net/browse/JDK-8200527
>
> API docs have been updated
+1 from me, thanks!
On Wed, Apr 18, 2018 at 3:09 PM, Xueming Shen wrote:
> Alan, David,
>
> Any more update/comment/suggestion on this one? I have updated
> DeInflate.java with
> some new test cases to cover the newly added methods. Good to go?
>
> -Sherman
>
> On 04/10/2018 08:49 PM, Xueming She
arcv9.
> The C comipler on
> solaris-sparcv9 platform does not like those "declaration follow a
> statement" new code in
> Deflater.c and Inflater.c
>
> http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/
>
> Thanks,
> Sherman
>
>
> On
FWIW I strongly doubt this will improve performance; probably the
opposite in fact, as IIRC an enum switch generates an extra class
(though perhaps this has changed). The original code was quite
compact and utilized identity comparisons, and given there are only
three alternatives it probably was
On Mon, Apr 23, 2018 at 7:42 PM, Isaac Levy wrote:
> On Mon, Apr 23, 2018 at 5:18 PM David Lloyd wrote:
>>
>> FWIW I strongly doubt this will improve performance; probably the
>> opposite in fact, as IIRC an enum switch generates an extra class
>> (though perhaps this
I feel like what you're looking for is really a general-purpose data
transformation API. I think bending charsets into this shape would be
a bad move, but I like the idea of a more generalized solution.
Google Guava has such an abstraction, and I know of a couple of others
a well.
On Thu, May 3,
1 - 100 of 115 matches
Mail list logo
