On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo wrote:
>> Pragmatically, fix the script to ignore those keywords on comment lines.
>> Learn Perl, its just a regular expression pattern match and replace
>> expression.
>>
>> All of the changes have to be manually reviewed by the author and then th
t case for this issue but it is getting more
> complex.
>
> Thanks,
> Vyom
>
> On Sat, Jul 4, 2020 at 8:14 PM Martin Buchholz wrote:
>>
>> On Fri, Jul 3, 2020 at 11:12 PM Alan Bateman wrote:
>>
>> > - "service" isn't a great name for the Exe
On Fri, Jul 3, 2020 at 11:12 PM Alan Bateman wrote:
> - "service" isn't a great name for the Executor. Also you can make use
> of try-finally, e.g.
> ExecutorService executor = Executors.newFixedThreadPool(1);
> try { ... } finally { executor.shutdown(); }
If you want to do this structured-concu
forwarded to other teams for review.
On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <
patr...@os.amperecomputing.com> wrote:
> Hi
>
> Please review this patch, if it should be reviewed by any group other than
> core-libs, please help forward it. Thanks.
>
> JBS: https://bugs.openjdk.java.net/br
;s a simple bug in Cache#remove that's easy to fix.
Nobody much likes LinkedList, but it does have the advantage of always
shrinking to fit its contents.
On Mon, Nov 4, 2019 at 7:09 AM Daniel Fuchs wrote:
> Hi Martin,
>
> On 02/11/2019 16:40, Martin Buchholz wrote:
> > Hi Julia
Hi Julia,
I think this is the wrong fix.
Looking at the Cache class - all the methods are synchronized, so it looks
like any failure is not actually due to concurrent execution, but any bug
can be reproduced in a single thread. (please add such a repro to the bug
report)
It looks like Cache#remo
Stuart's cool type system hack is hard for me to grok, but it seems alright
to put into ConcurrentSkipListMap.java. We could add it to the current
jsr166 integration.
*From: *Stuart Marks
*Date: *Thu, May 16, 2019 at 3:11 PM
*To: *Martin Buchholz, David Holmes, Doug Lea, Langer, Christop
On Thu, May 16, 2019 at 4:05 PM David Holmes
wrote:
> On 17/05/2019 8:57 am, Martin Buchholz wrote:
> > Maybe you just need to ask gcc to use a more modern -std=...
> > It might reasonably be defaulting to gnu89
> >
> https://stackoverflow.com/questions/14737104/what-i
Maybe you just need to ask gcc to use a more modern -std=...
It might reasonably be defaulting to gnu89
https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu
On Thu, May 16, 2019 at 3:25 PM David Holmes
wrote:
> On 16/05/2019 11:41 pm, A
I feel the same as David - reluctant to change anything. Introducing a raw
type makes an ugly cast uglier.
*From: *David Holmes
> >
> src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
>
> As you note this should be ok'd by jsr166 folk so I've cc'd Martin
> Buccholz. I
TIL that we had tests with security policies so fine-grained that test
libraries were granted more permissions than other test code.
grant codeBase "file:${test.classes}/../../../../test/lib/-" {
Given that, I agree with Chris and Daniel that test library code should
include the same doPrivileged
On Thu, May 2, 2019 at 2:28 AM Daniel Fuchs wrote:
>
> 1. IPSupport needs to read system properties, attempts
> to bind sockets etc... I wonder how that might interact
> with tests that use a security manager, as some of these
> operations may throw a SecurityException.
> Maybe so
On Wed, Apr 17, 2019 at 10:58 AM Arthur Eubanks wrote:
> It turns out these patches only apply to a modified kernel which has
> patches to turn off IPv4. This specific patch doesn't make sense to submit
> if the kernel patches are not upstream.
>
I disagree a little.
Google may be decades ahead,
Sorry for never having had the time to finish
https://bugs.openjdk.java.net/browse/JDK-8179037
Improve IPv6 support
On Mon, Apr 1, 2019 at 6:12 AM Chris Hegarty
wrote:
> Arthur, others,
>
> In order to help track the all the IPv6 related work, we have the
> following issues:
>
> Improved IPv6 Su
Looks good to me.
On Tue, Mar 19, 2019 at 1:48 PM Alan Bateman
wrote:
> Looks okay, surprised this wasn't noticed before.
>
It was!
On Wed, Mar 13, 2019 at 11:24 AM Daniel Fuchs
wrote:
>
> jshell> InetAddress.getLoopbackAddress().getHostName()
> $7 ==> "localhost"
>
> jshell> InetAddress.getAllByName("localhost");
> $8 ==> InetAddress[3] {
>localhost/127.0.0.1,
>localhost/0:0:0:0:0:0:0:1,
>
On Wed, Mar 13, 2019 at 11:49 AM Chris Hegarty
wrote:
>
> > At Google, we have our own hacks to test ipv6-only environments, based
> > on either LD_PRELOAD or eBPF (but it would take work to share them even
> > in minimally functional form)
>
> Maybe I can produce something similar and publish it
On Tue, Mar 12, 2019 at 12:21 PM Chris Hegarty
wrote:
>
> > Just curious, what tests did you run and under what environment?
>
> I ran all java/net, sun/net, com/sun/net/, and some nio. I'm have a bit
> of a hacky environment: a JDK build with IPV6_V6ONLY set to 1, and
> preferIPv6Addresses effec
Looks good to me.
On Wed, Mar 13, 2019 at 9:34 AM Arthur Eubanks wrote:
> Hi,
>
> A fix for some sample code in MulticastSocket, which assumed that
> String.length() == String.getBytes().length, which is not true for
> non-ASCII Strings.
>
> http://cr.openjdk.java.net/~aeubanks/8220585/webrev.00
These changes are clean progress and allow tests to pass on any of the 4
(!) combinations of IPV4/IPV6 support available. LGTM.
BUT ... in the current multi-protocol world it's probably better to test
against all the interfaces available on the host machine.
Maybe there should be a InetAddress.ge
Tested with
$ make test TEST="test/jdk/com/sun/net/httpserver
test/jdk/com/sun/nio/ test/jdk/java/net test/jdk/java/nio/channels
test/jdk/java/rmi/transport/ test/jdk/jdk/net/ test/jdk/sun/net/"
That's useful information, but unfortunately jcheck will reject it. Please
edit the commit metadata
On Mon, Mar 11, 2019 at 10:18 AM Daniel Fuchs
wrote:
>
> Also please update the copyright years in the files you're
> changing.
>
> Google policy is to leave Copyright years in source files untouched.
Especially another company's!
All backports become visible on the master bug
https://bugs.openjdk.java.net/browse/JDK-8218554
e.g.
https://bugs.openjdk.java.net/browse/JDK-8217319
On Mon, Feb 11, 2019 at 10:26 AM Wenbo Zhu wrote:
> Thanks for the fix!
>
> I am new to this and could you let me know how to find out the target
Thanks. Looks good.
Tangentially ... I see URLClassLoader uses URLClassPath which uses
FileURLMapper, which tries to directly convert a URL to a String path.
FileURLMapper uses URL#getFile, and TIL that #getFile differs from #getPath
in that it also returns a query component where present.
Maybe
See also
https://bugs.openjdk.java.net/browse/JDK-8213218
https://bugs.openjdk.java.net/browse/JDK-8213220
On Mon, Nov 12, 2018 at 10:29 AM, Pavel Rappo
wrote:
> > On 12 Nov 2018, at 18:14, Alan Bateman wrote:
> >
> > It will need a CSR because it changes Inet6Address to specify that it
> can b
I agree with this approach - it parallels the efforts made with O_CLOEXEC
in past years.
According to
https://www.freebsd.org/cgi/man.cgi?query=socket&sektion=2
SOCK_CLOEXEC is also available on freebsd.
On Tue, Jul 10, 2018 at 1:36 AM, Andrew Luo <
andrewluotechnolog...@outlook.com> wrote:
> Hi
r the default and assume that
multiple String concatenation does in fact get optimized.
I'm not planning to check in the benchmark code.
On Tue, Dec 5, 2017 at 2:10 AM, Chris Hegarty
wrote:
>
> > On 5 Dec 2017, at 04:01, Martin Buchholz wrote:
> >
> > http://cr.openj
http://cr.openjdk.java.net/~martin/webrevs/jdk/URL.toExternalForm/
Any change that fiddles with "available" is never simple!
I confess to not understanding sockets, but intuitively they differ from
files in that eof is a murky concept - there may not be any data from the
other end of the socket right now, but who knows what's coming soon?
What's the difference be
On Mon, Mar 20, 2017 at 2:46 PM, Alexander Smundak
wrote:
> Should this be a patch for JDK9 or JDK10?
>
It's too late for jdk9 initial release, although we might backport to
jdk9.1.
On Mon, Mar 20, 2017 at 7:14 AM, Chris Hegarty
wrote:
>
>> I should point out that the current batch of changes are focused on
>> support for systems where 127.0.0.1 doesn't exist, which is relatively
>> straightforward and unexciting.
>>
>
> Sorry, what does this mean. IPv6-only environment with
Google cares a lot about IPv6, and not only because Vint Cerf works at
Google.
We have some local modifications and some networking expertise and intend
to port/contribute that to openjdk10.
Most of this is the work of my colleagues Alexander Smundak and Paul Marks.
We hope we can do most of thi
It would not have both the never-null property and the check for null.
I would probably just leave bindings null in the constructor and check for
null whenever reading bindings.
On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard
wrote:
> Hi,
>please oblige and review the change
> http://cr.openj
On Wed, Sep 7, 2016 at 10:15 AM, Michael McMahon <
michael.x.mcma...@oracle.com> wrote:
>
> [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/
>
> [2] http://cr.openjdk.java.net/~michaelm/httpclient/
> specdiffout.1/package-summary.html
>
Could we have actual source code for experimentati
I don't know much about http, but I believe those who say that it's very
hard to get the API right. Perhaps it would be best to deliver a http
client library as an independent beta package for use with jdk 8+ with a
final version becoming part of jdk 10? Perhaps there can be a productive
collabor
On Tue, Aug 23, 2016 at 12:57 PM, Wenbo Zhu wrote:
>
>> We are currently working in the sandbox repository again and will have
>> these changes
>> in the main JDK9 dev forest soon.
>>
> Is it possible to access the API code somewhere before then, mainly as a
> convenience for reviewing the APIs?
I'm (slowly) working on getting you more ipv6 stuff...
On Thu, May 12, 2016 at 8:32 AM, Chris Hegarty wrote:
> Martin,
>
> Promoted by some other changes that are going on, I stumbled
> across your proposal for 8148424: "Support IPv6-only Unix
> environments” [1][2][3].
>
> I think the changes ar
On Sun, Apr 10, 2016 at 10:19 PM, Andrej Golovnin
wrote:
>> On Sun, Apr 10, 2016 at 2:00 PM, Andrej Golovnin
>> wrote:
>>> BTW, someone should describe in the JavaDocs of
>>> CompletableFuture#orTimeout()
>>> what would happen when this method is called multiple times on the same
>>> Completable
On Sun, Apr 10, 2016 at 2:00 PM, Andrej Golovnin
wrote:
> BTW, someone should describe in the JavaDocs of CompletableFuture#orTimeout()
> what would happen when this method is called multiple times on the same
> CompletableFuture with different arguments.
Hmmm the javadoc seems clear enough to me
Are y'all interested in our ipv6-only changes?
https://bugs.openjdk.java.net/browse/JDK-8148424
If yes, there will be some work on both sides, mostly for
multi-platform testing.
[+net-dev]
On Sat, Sep 5, 2015 at 11:58 PM, Sebastian Sickelmann <
sebastian.sickelm...@gmx.de> wrote:
> Please find my small patch[1] to javadoc in java.net.URL that adresses
> JDK-4906983(javadoc-fix)[2].
>
> -- Sebastian
>
> [1]
>
> https://dl.dropboxusercontent.com/u/43692695/oss-patches/open
I haven't looked at the patch, but generally ... all uses of
currentTimeMillis to measure elapsed time should be migrated to use
difference of two nanoTime values, and such a change should be done
independently of other changes.
IIRC lookup.sh is a known flaky test being fixed elsewhere.
On Tue,
Hi Joe,
On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy wrote:
>
> Should third-party vendor extensions that are "supported" for public use
> by the third-party use jdk.Supported?
>
>
> No; as I envision it, the jdk.Supported annotation is only meant to convey
> supported-ness in the JDK of parts o
On Thu, Feb 21, 2013 at 6:16 PM, Joe Darcy wrote:
>
> However, the com.sun.* subpackages are a mix of APIs that are supported as
> described above as well as APIs that are not supported.
I was under the impression that the general rule was that all of com.sun.*
fell under the "jdk supported" um
Pushed.
On Mon, Dec 17, 2012 at 11:18 PM, Chris Hegarty wrote:
> Thank you Martin, looks good.
>
> -Chris
>
> On 18 Dec 2012, at 02:45, Martin Buchholz wrote:
>
> I created a webrev
>
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/KeepAliveStream-infloop/
I created a webrev
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/KeepAliveStream-infloop/
incorporating Chris' test and propose to push this change to
ssh://mar...@hg.openjdk.java.net/jdk8/tl-gate/jdk
skip(nskip);
> +nskip = expected - count;
> }
>
>
I was trying to avoid ever calling skip with a larger argument than
available(), trying to obey the comment
// Do this ONLY if the skip won't block.
So my version feels safer, although agai
On Tue, Dec 11, 2012 at 7:40 AM, Chris Hegarty wrote:
> Hi Martin,
>
> Thank you for reporting this issue. I filed 8004863: "Infinite Loop in
> KeepAliveStream", to track it.
>
> I put together a small test to reproduce the problem (inline below). It is
> racey, but shows the problem most of the t
Hi sun/net/www maintainers,
Here at Google we have observed an infinite loop
in jdk/src/share/classes/sun/net/www/http/KeepAliveStream.java
85: if (nskip <= available()) {
86: long n = 0;
87: while (n < nskip) {
88:
NULL)
error_string = "unknown error";
Webrev regenerated.
Martin
On Wed, Sep 1, 2010 at 10:51, Martin Buchholz wrote:
>
>
> On Wed, Sep 1, 2010 at 06:27, Michael McMahon <
> michael.x.mcma...@oracle.com> wrote:
>
>> Martin Buchholz wrote:
>>
&g
On Wed, Sep 1, 2010 at 06:27, Michael McMahon
wrote:
> Martin Buchholz wrote:
>
>> Hi net maintainers,
>>
>> I'd like you to do a code review.
>>
>> I got frustrated with incomplete information from exceptions thrown from
>> java.net <http://java.
Hi net maintainers,
I'd like you to do a code review.
I got frustrated with incomplete information from exceptions thrown from
java.net, so I hacked up some fixes for them. This is the result.
generify; remove compiler warnings, typos, casts; return status
information via gai_strerror when geta
g.Throwable.getStackTraceDepth ... JNI]
[Dynamic-linking native method java.lang.Throwable.getStackTraceElement ... JNI]
at Test.testNative(Native Method)
at Test.(Test.java:4)
Martin
On Wed, Jun 9, 2010 at 03:25, David Holmes wrote:
> Hi Martin,
>
> Turns out th
Hi ClassLoader maintainers,
This is a bug report.
(I think this is a hotspot bug, but it might be a core library
ClassLoader bug or even a URLClassLoader bug)
If you use RegisterNatives with a class loaded using URLClassLoader,
you must call GetMethodID
before RegisterNatives, or you get an Unsa
Hi net-dev gang,
A colleague reports that:
URLConnection.getRequestProperties() promises to throw an
IllegalStateException when invoked on a connected instance. But Java 6
returns a valid map.
Can you get either the spec or the implementation fixed so that the two agree?
Thanks,
Martin
Hi Alan,
This is a bug report with fix. Please review.
webrev:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/EPollArrayWrapper.release/
Synopsis: EPollArrayWrapper.release should be O(N), not O(N^2)
Description:
In a recent email, I said
"no one is really using LinkedList
in performance-
Hello net wranglers,
Sorry for being such a stranger to this mailing list.
Anyways, here's a bug report:
If you test java/net/Authenticator/B4769350.java with
-vmoption:-enablesystemassertions,
you get an assertion failure as follows (please fix):
jtreg -v:nopass,fail -vmoption:-enablesystemass
bout what happens when other people run
> it. I am also interested in confirming that this is a sane use of Selectors,
> SocketChannels, and SelectionKeys.
>
> Thanks,
> Ariel Weisberg
>
> On Wed, 15 Jul 2009 14:24 -0700, "Martin Buchholz"
> wrote:
>
> In su
On Mon, Feb 2, 2009 at 05:42, Christopher Hegarty - Sun Microsystems
Ireland wrote:
> +static int isAsciiSpace(char c) {
> + return (((c) == '\t') || ((c) == '\r') || ((c) == '\b') ||
> + ((c) == '\n') || ((c) == ' ') );
> +}
> +
A very minor comment -
the parens around (c) are a very
60 matches
Mail list logo
