Hi Langer,
Thanks for working on this issue. I will take a look into the
implementation details
next week. Here are two comments regarding the "direction/approach".
(1) There is a "masked" security concern regarding adding the
"ownership/permission" into
the jar file.
"Security concern:
Th
On 9/28/18 1:59 AM, Alan Bateman wrote:
On 28/09/2018 08:28, Ichiroh Takiguchi wrote:
Hello.
One of JDBC application with JavaDB did not work on JDK12.
Following exception happened:
java.sql.SQLException: No suitable driver found for jdbc:derby:xx
I assume, this issue related Modulari
On 09/28/2018 04:13 AM, Alan Bateman wrote:
On 28/09/2018 05:51, Tagir Valeev wrote:
Hello!
I can volunteer doing this if OpenJDK community is really interested.
I've launched the inspection over all java.* and jdk.* modules and
found 4064 warnings.
As an example, I converted all C-style arr
Hi Francesco,
Thanks for the pointer to AtomicBuffer stuff. It's quite interesting.
I don't know how directly relevant this JEP is your work. I guess that's really
up to you and possibly Andrew Dinn. However, in my thinking, if you have useful
comments and relevant questions, you're certainly
On 9/28/18 12:21 AM, Peter Levart wrote:
I mostly agree with your assessment about the suitability of the ByteBuffer API
for nice multithreaded use. What would such API look like? I think pretty much
like ByteBuffer but without things that mutate mark/position/limit/ByteOrder. A
stripped-dow
On 9/28/18 2:16 AM, Andrew Dinn wrote:
Thanks for clarifying that point. I have already added a note to that
effect to the JEP. I take your other point that these limitations make
this JEP a less useful addition than it could be. However, it's hard to
see what else might usefully be provided t
I can review the changes in java.desktop, please use these email alias
awt-dev/2d-dev/swing-dev.
On 28/09/2018 04:13, Alan Bateman wrote:
As regards doing the entire source base then I think that would be good.
Due to the complexity of testing, changes to the java.desktop module are
pushed to
Hi Pallavi,
Please file a CSR for this, as this will change the behavior.
Naoto
On 9/28/18 8:53 AM, Pallavi Sonal wrote:
Thanks Roger. I will update it before the commit.
-Original Message-
From: Roger Riggs
Sent: Friday, September 28, 2018 6:15 PM
To: Pallavi Sonal ; core-libs-dev
Thanks Roger. I will update it before the commit.
-Original Message-
From: Roger Riggs
Sent: Friday, September 28, 2018 6:15 PM
To: Pallavi Sonal ; core-libs-dev
Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle
offsets
Hi Pallavi,
Looks fine,
But can you r
I’ll create back port requests.
Cheers,
Henry
> On Sep 27, 2018, at 11:06 PM, Bo Zhang wrote:
>
> Thanks Henry, this change looks good to me. I assume this patch will be
> backported to 11GA, will it be back ported to 10 as well?
>
> Regards,
> Bo
>
>> On 28 Sep 2018, at 00:49, Henry Jen w
I would like to tell about some steps towards formal check of Raffaello's
human proof.
I work on formal verification of some Oracle projects but they are
unrelated to JDK.
In April Brian Burkhalter requested me to review the Raffaello's paper.
His paper is smart and clear but nevertheless I was afr
Will do.
Cheers,
Henry
> On Sep 28, 2018, at 3:23 AM, Alan Bateman wrote:
>
>
>
> On 27/09/2018 17:49, Henry Jen wrote:
>> Agree, please find updated webrev[1].
>>
>> [1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
>>
>>
> This looks okay to me, you may want to consider add
On Fri, Sep 28, 2018 at 4:13 PM Andrew Haley wrote:
>
> On 09/28/2018 02:55 PM, Volker Simonis wrote:
> > I agree that the native code should be fixed and I think your patch is
> > correct.
> >
> > Nevertheless I'd vote for changing it to something like:
> >
> > old = (tio.c_lflag & ECHO) == 0 ?
Ping...
Are there any reviews/comments on my proposal for adding unix/posix permissions
to zip APIs?
Thanks
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Mittwoch, 26. September 2018 09:49
> To: 'Alan Bateman' ; core-libs-
> d...@openjdk.java.net; nio-dev ; Xueming
>
On 09/28/2018 02:55 PM, Volker Simonis wrote:
> I agree that the native code should be fixed and I think your patch is
> correct.
>
> Nevertheless I'd vote for changing it to something like:
>
> old = (tio.c_lflag & ECHO) == 0 ? JNI_FALSE : JNI_TRUE;
>
> It's slightly more verbose, but it makes
Hi Andrew,
I agree that the native code should be fixed and I think your patch is correct.
Nevertheless I'd vote for changing it to something like:
old = (tio.c_lflag & ECHO) == 0 ? JNI_FALSE : JNI_TRUE;
It's slightly more verbose, but it makes it more obvious that a JNI
function returning a jb
> On 26 Sep 2018, at 02:41, James Roper wrote:
>
> Sounds good to me, I'll ping Viktor to make sure he sees it too.
The "Synchronization primitives in Reactive Streams implementations" thread on
concurrency-interest mailing list:
http://cs.oswego.edu/pipermail/concurrency-interest/2018-S
Hi Pallavi,
Looks fine,
But can you re-wrap the lines with the new links, they got longer than
100 chars with the link.
No new webrev is needed.
Thanks, Roger
On 9/28/18 8:35 AM, Pallavi Sonal wrote:
Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
http://c
Thanks Roger and Stephen. Here is the updated webrev with the suggested changes:
http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/
Thanks,
Pallavi Sonal
-Original Message-
From: Roger Riggs
Sent: Friday, September 28, 2018 12:51 AM
To: core-libs-dev
Subject: Re: RFR: JDK-8166138 - D
On 28/09/2018 05:51, Tagir Valeev wrote:
Hello!
I can volunteer doing this if OpenJDK community is really interested.
I've launched the inspection over all java.* and jdk.* modules and
found 4064 warnings.
As an example, I converted all C-style array declarations in java.base
module (660 warning
On 27/09/2018 17:49, Henry Jen wrote:
Agree, please find updated webrev[1].
[1] http://cr.openjdk.java.net/~henryjen/jdk/8210810/1/webrev/
This looks okay to me, you may want to consider adding 8210810 to the
@bug tag before pushing.
-Alan
Hi Stuart,
On 28/09/18 06:51, Stuart Marks wrote:
> Let me first stay that this issue of "ByteBuffer might not be the right
> answer" is something of a digression from the JEP discussion. I think
> the JEP should proceed forward using MBB with the API that you and Alan
> had discussed previously.
On 28/09/2018 08:28, Ichiroh Takiguchi wrote:
Hello.
One of JDBC application with JavaDB did not work on JDK12.
Following exception happened:
java.sql.SQLException: No suitable driver found for jdbc:derby:xx
I assume, this issue related Modularity feature...
I could not solve this issue b
Hello.
One of JDBC application with JavaDB did not work on JDK12.
Following exception happened:
java.sql.SQLException: No suitable driver found for jdbc:derby:xx
I assume, this issue related Modularity feature...
I could not solve this issue by myself.
In order to investigate the root cau
Hi Stuart,
I mostly agree with your assessment about the suitability of the
ByteBuffer API for nice multithreaded use. What would such API look
like? I think pretty much like ByteBuffer but without things that mutate
mark/position/limit/ByteOrder. A stripped-down ByteBuffer API therefore.
Tha
25 matches
Mail list logo
