Hi everyone,
could you please review my change for JDK-8037781:
http://cr.openjdk.java.net/~chegar/8037781/webrev.00/
After JDK-8035158 was fixed we freed our hands to remove these 4 classes:
1. sun.misc.RegexpPool,
2. sun.misc.RegexpTarget,
3. sun.misc.Regexp,
Hi Sean, Sherman
as far as the client is using ZipFileInputStream in a multithreaded fashion (de
facto), don't we have to rethink synchronization for the machinery of
ZipFileInputStream.read? As far as I understand it's not enough to put this
particular read of 'rem' into the synchronized
Given the amount of mutual exclusion and synchronization already involved, I
wonder if it's worth making it thread-safe after all. And (idialy) forget about
races there forever.
-Pavel
On 10 Apr 2014, at 11:35, Seán Coffey sean.cof...@oracle.com wrote:
This should make the code more robust
Hi everyone,
could you please review my change for JDK-8038178?
P.S. Some may find this a little bit amusing.
Thanks
-Pavel
diff --git a/src/share/classes/sun/misc/InnocuousThread.java
b/src/share/classes/sun/misc/InnocuousThread.java
--- a/src/share/classes/sun/misc/InnocuousThread.java
+++
Hi everyone,
could you please review my change for JDK-7153400?
http://cr.openjdk.java.net/~chegar/7153400/00/webrev/
http://ccc.us.oracle.com/7153400
It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has
been agreed with Doug Lea. The exact same change (except for the
the core pool size
*/
-Pavel
On 14 May 2014, at 18:03, Mike Duigou mike.dui...@oracle.com wrote:
Hi Pavel;
The change and test looks good. Will the test be upstreamed or will Doug be
adding a similar test in his upstream?
Mike
On May 14 2014, at 08:29 , Pavel Rappo pavel.ra
Oh I see, thanks.
-Pavel
On 14 May 2014, at 20:56, Doug Lea d...@cs.oswego.edu wrote:
On 05/14/2014 03:15 PM, Pavel Rappo wrote:
Hi Mike,
Unfortunately I don't know. I suppose it is better to rely on our own jdk
tests. The only thing I did was sent Doug 2 patches for the tck tests
be
adding a similar test in his upstream?
Mike
On May 14 2014, at 08:29 , Pavel Rappo pavel.ra...@oracle.com wrote:
Hi everyone,
could you please review my change for JDK-7153400?
http://cr.openjdk.java.net/~chegar/7153400/00/webrev/
http://ccc.us.oracle.com/7153400
It's
());
}
joinPool(p);
}
}
On Wed, May 14, 2014 at 2:02 PM, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi Martin,
Thanks for you comments. I forgot indeed that awaitTermination indicates its
result by returning a boolean value rather than throwing TimeoutException. So
Hi everyone,
could you please review my change for JDK-8042887?
http://cr.openjdk.java.net/~alanb/8042887/webrev/
I also created following issues for appropriate docs/localization updates:
https://bugs.openjdk.java.net/browse/JDK-8043613
https://bugs.openjdk.java.net/browse/JDK-8043620
Thanks
2014, at 14:32, Chris Hegarty chris.hega...@oracle.com wrote:
This looks good to me.
Trivially, I think you could remove the 3 and 4 arg Res.getText methods, as I
don’t see them being used.
-Chris.
On 22 May 2014, at 09:47, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi everyone,
could
Hi everyone,
Could you please review my change for JDK-8046768?
http://cr.openjdk.java.net/~prappo/8046768/webrev.00/
This change doesn't fix the issue. It barely adds a diagnostic output
(LdapTimeoutTest.java:167) for the case that is failing. During my
investigation I haven't been able to
I will close this bug with resolution Cannot Reproduce and create a new one.
I think this should be the right way to go.
Apologies.
-Pavel
On 17 Jun 2014, at 13:32, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi everyone,
Could you please review my change for JDK-8046768?
http
Hi everyone,
Could you please review my change for JDK-8047062?
http://cr.openjdk.java.net/~prappo/8047062/webrev.00/
Thanks
-Pavel
I created an issue to track the progress and also made 2 webrevs. One for the
original patch and one for the changes that have been suggested earlier in this
thread by Paul and Andrej. Here we go:
https://bugs.openjdk.java.net/browse/JDK-8048267
On Fri, Jun 27, 2014 at 12:00 PM, Pavel Rappo pavel.ra...@oracle.com wrote:
I created an issue to track the progress and also made 2 webrevs. One for the
original patch and one for the changes that have been suggested earlier in
this thread by Paul and Andrej. Here we go:
https
. Before the change, long was truncated to fit int. And now it's
not.
P.S. Andrej, it looks like you don't have an 'Author' status. Well, that's a
pity. We could mention you in the 'Reviewed-by' line. Your contributions are
really good.
-Pavel
On 27 Jun 2014, at 11:52, Pavel Rappo pavel.ra
I've updated the webrev. It includes all the changes we've discussed so far
plus these:
http://cr.openjdk.java.net/~prappo/8048267/webrev.03/src/macosx/classes/sun/font/CStrike.java.sdiff.html
time. I hope you
didn't committed the patch for the Longs yet. There were also changes to the
classes in the package jdk.internal.org.objectweb.asm.
Best regards,
Andrej Golovnin
On Tue, Jul 1, 2014 at 2:39 PM, Pavel Rappo pavel.ra...@oracle.com wrote:
Otavio,
As with [1], I created
:04, Pavel Rappo pavel.ra...@oracle.com wrote:
If a test run finishes fine, I'll push this version (no
Unsafe*LongFieldFieldAccessorImpl.java files included):
http://cr.openjdk.java.net/~prappo/8048267/webrev.04/
-Pavel
On 30 Jun 2014, at 11:31, Andrej Golovnin andrej.golov...@gmail.com
Hi Peter,
Just a minor subjective issue. I would suggest changing the name of the local
variable 'factory' in java.net.URL.getURLStreamHandler method for something
different. It's a bit hard to read the code since this variable clashes with
the same-name class field.
Thanks,
-Pavel
On 3 Jul
Hi Otavio,
Other than things already spotted by Andrej, the change looks good to me. Thank
you for doing this.
-Pavel
On 11 Jul 2014, at 02:36, Otávio Gonçalves de Santana
otaviopolianasant...@gmail.com wrote:
https://bugs.openjdk.java.net/browse/JDK-8049892
Hi everyone,
Could you please review my change for JDK-8049884?
http://cr.openjdk.java.net/~prappo/8049884/webrev.00/
Thanks
-Pavel
Hi everyone,
Could you please review my change for JDK-8048175?
http://cr.openjdk.java.net/~prappo/8048175/webrev.00/
Summary
1. com.sun.jndi.ldap.Connection imports both java.net.InetSocketAddress and
javax.net.SocketFactory which are available since 1.4
2.
management rmi) and the CORBA regression suite
for the changeset, with no perceptible issues
regards
Mark
On 14/07/2014 12:43, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8048175?
http://cr.openjdk.java.net/~prappo/8048175/webrev.00/
Summary
1
Hi everyone,
Could you please review my change for JDK-8050869?
http://cr.openjdk.java.net/~prappo/8050869/webrev.00/
Thanks
-Pavel
Hi everyone,
Could you please review my change for JDK-8051350?
http://cr.openjdk.java.net/~prappo/8051350/webrev.00/
This is just a one-liner javadoc fix.
-Pavel
Hi everyone,
Could you please review my change for JDK-8051991?
http://cr.openjdk.java.net/~prappo/8051991/webrev.00/
-Pavel
Hi everyone,
Could you please review my change for JDK-8051422?
http://cr.openjdk.java.net/~prappo/8051422/webrev.00/
-Pavel
Hi everyone,
Could you please review my change for JDK-8054158?
http://cr.openjdk.java.net/~prappo/8054158/webrev.00/
-Pavel
On 8/1/2014 11:50 AM, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8054158?
http://cr.openjdk.java.net/~prappo/8054158/webrev.00/
-Pavel
In the class
src/share/classes/javax/management/openmbean/CompositeType.java you have
added the
annotation @SuppressWarnings(StringConcatenationInsideStringBufferAppend)
instead of fixing the concatenation inside the append method. Why?
+1 Moreover, I wonder where this value comes from? I've
Otavio,
Just skimmed through your changes. It looks good. But there are some things we
can make a little bit better though. IMO, it's not always a performance that
matters (looking around to see if Alexey Shipilev is somewhere near) but
readability. It's good to estimate performance
saved us, but there isn't one.
(I'm sure there were plenty of engineering reasons not to do things I've
mentioned)
-Pavel
On 11 Aug 2014, at 16:38, Ulf Zibis ulf.zi...@cosoco.de wrote:
Am 11.08.2014 um 16:33 schrieb Pavel Rappo:
Unfortunately, neither java.util.StringJoiner nor String.join
Sorry, I should've written this:
Iterable? whatever = ...
StringJoiner joiner = new StringJoiner(, );
whatever.forEach(w - joiner.add(w.toString()));
String s = joiner.toString();
-Pavel
On 11 Aug 2014, at 17:17, Pavel Rappo pavel.ra...@oracle.com wrote
Hi everyone,
Could you please review my change for JDK-8054857?
http://cr.openjdk.java.net/~prappo/8054857/webrev.00/
It's just a bunch of misspellings and typos in comments and javadoc.
Thanks
-Pavel
Yup,
HG:
changeset: 4823:194faa6fdb3c
user: sherman
date: Mon Dec 05 10:50:14 2011 -0800
files: src/share/classes/java/util/Formatter.java
test/java/util/MissingFormatArgumentException/GetFormatSpecifier.java
description: 5063455: (fmt) MissingFormatArgumentException.getFormatSpecifier()
Brian,
Yes, this works fine in cases when 'whatever' is a j.u.Collection? extends
CharSequence (though some may argue that it's an overkill already). However we
need even more thinking and transformations in case when 'whatever' is one of
these:
* j.u.Iterator? extends CharSequence
*
It's exactly the way it's been working since 1.6 I believe.
source
public class Optimization {
public String concat(String... strings) {
return #: + strings[0] + strings[2] + strings[3] + ...;
}
}
compiled into
public class Optimization {
public Optimization();
Code:
Could you please explain what you mean by javac optimization fails here?
-Pavel
On 27 Aug 2014, at 10:41, Ulf Zibis ulf.zi...@cosoco.de wrote:
4.) Now we see, that javac optimization fails again if StringBuilder,
concatenation, toString(), append(String), append(Collection) etc. and
Hi everyone,
Is there any particular reason why there's no convenience method for iterators
similar to j.u.Collections.list for enumerations? Or at least the one that
adapts Iterator to Enumeration and vice versa. Thanks.
-Pavel
If we were to provide a Collections util it would to wrap Enumeration as an
Iterator but that's it.
Mike, that's what I'm talking about. It's just for convenience.
-Pavel
Hi everyone,
We are thinking of removing the extcheck tool. For those who doesn't remember
what it is, here is an extract from its man page:
extcheck(1)
NAME
extcheck - jar conflict detection utility
SYNOPSIS
extcheck [ -verbose ] [ -Joption ] targetfile.jar
DESCRIPTION
The
Hi everyone,
Could you please review my change for JDK-8044627?
http://cr.openjdk.java.net/~prappo/8044627/webrev.00/
-Pavel
Daniel,
Given that helper.loadClass uses the context class loader,
Should you also simply use
ServiceLoaderInitialContextFactory loader =
ServiceLoader.load(InitialContextFactory.class);
at lines 680-681 ?
It needs to be the system class loader to allow for JNDI
Daniel,
So is it expected that modules (e.g. java.corba) will register
their own service provider for the InitialContextFactory
(I mean - using META-INF/services/)?
Alan's already answered this point. TCCL is the way to go. You are right.
The difference however is that in this two case
OK, so what I will do for now is I exclude these 4 files and push without them.
I'll create a new issue to add them later.
-Pavel
On 14 Oct 2014, at 14:44, Alan Bateman alan.bate...@oracle.com wrote:
On 14/10/2014 14:34, Daniel Fuchs wrote:
Hi Pavel,
I saw your mail on build-dev.
I guess
Thanks a lot!
-Pavel
On 14 Oct 2014, at 15:33, Chris Hegarty chris.hega...@oracle.com wrote:
META-INF files in the webrev, two of which are in the wrong location. They
are directly under 'META-INF’, where they should all be under
‘META-INF/services’. This is just a note for Pavel, when he
Hi everyone,
Could you please review my change for JDK-8042888?
http://cr.openjdk.java.net/~prappo/8042888/webrev.00/
Previously I sent an email to see if anyone uses this tool or has any thoughts
on its future [1].
Hi everyone,
Could you please review my change for JDK-8062759?
http://cr.openjdk.java.net/~prappo/8062759/webrev.00/
P.S. The actual change is located at lines [215, 219]. Everything else is just
a minor refactoring.
P.P.S. I
Hi everyone,
Could you please review my change for JDK-8059311?
http://cr.openjdk.java.net/~prappo/8059311/webrev.00/
It looks like one of the killSwitches went off and executed System.exit(0).
The problem is jtreg doesn't like
Hi everyone,
I've been working with the URLConnection class for some time now and have
noticed several interesting things.
1. Unsafe publication of java.net.URLConnection.factory static field (it looks
very similar to [1])
2. Benign race condition in java.net.URLConnection.getContentHandler on
Hi Patrick,
There is at least one method in the JDK with similar characteristics:
java.nio.file.Files#copy(java.io.InputStream, java.io.OutputStream)
But, (1) it has a private access (2) even if we made it public I doubt
java.nio.file.Files would be a good place for it
P.S. The thing that
Paul, I wouldn't name it 'ByteStreams' because of the possible subjective
associations (and confusion) with java.util.stream.IntStream,
java.util.stream.LongStream, etc.
IOStreams?
-Pavel
On 24 Nov 2014, at 14:32, Paul Sandoz paul.san...@oracle.com wrote:
i recommend creating a new class
I've created an initial webrev for this change:
http://cr.openjdk.java.net/~prappo/ioutil/webrev.00/
Welcome to discussion.
P.S. The only thing I changed was the license header.
-Pavel
On 27 Nov 2014, at 09:48, Patrick Reinhart patr...@reini.net wrote:
Hi Paul,
Seems not to work. See
At the bare minimum I would use runtime null/range checks and give a little bit
more freedom for those who want to control buffer (or probably reuse already
existing one): http://cr.openjdk.java.net/~prappo/ioutil/webrev.01/
I would also add some clarifications in the javadoc.
-Pavel
Patrick, as soon as I get feedback from Alan and Paul I'll merge these changes
into the current version.
1. I wonder if it makes sense to provide an additional method where client
specifies CharBuffer to be used?
Moreover if the first argument is CharSequence then we don't even need a buffer:
Yes I will. If I don't see any objections.
-Pavel
On 27 Nov 2014, at 16:10, Patrick Reinhart patr...@reini.net wrote:
Will you add those changes additionally to mine then?
. The good start could be the
jdk itself -- to see if those copy-with-my-buffer methods could be useful here.
-Pavel
On 27 Nov 2014, at 17:40, Patrick Reinhart patr...@reini.net wrote:
Am 27.11.2014 um 17:57 schrieb Alan Bateman alan.bate...@oracle.com:
On 27/11/2014 15:56, Pavel Rappo wrote
I'm happy with any tool which is capable of usages search. Configured IDE is
a good choice.
-Pavel
On 27 Nov 2014, at 22:59, Patrick Reinhart patr...@reini.net wrote:
I have to say, that I normally use my IDE to search for references.
What technique do you use to search for such
What usage would you actually search in the OpenJDK code base?
We're talking about copying with provided buffer, right?
long copy(InputStream source, OutputStream target, byte[] buffer)
^
It would be very helpful to verify that
Nathan, thanks a lot for reporting this. Sorry no one has replied to you
earlier,
but your bug report was actually entered into the JBS (JDK Bug System):
https://bugs.openjdk.java.net/browse/JDK-8054565
So don't worry, it won't get lost.
Now about the issue itself. It's indeed a bug.
Patrick, thanks a lot for doing this! I've had a look at these usages, and I
think it's safe to say that in the JDK it has never been required (yet) to
provide a copy method with custom byte array. So let's skip it for now.
I think more and more about your initial suggestion of introducing a
Patrick,
Should those methods also be on the FilterInput- and OutputStream?
I'm not sure I'm following you. j.i.FilterInputStream will get the base version
of InputStream.copyTo method for free as a child though it doesn't define it
itself. Every class down the hierarchy starting from the
Hello,
also using a stream in a multi threaded way is quite unusual most of
the implementations I have seen use a atomic solution.
Bernd, as far as I understand we are not talking about concurrent-proof solution
for the j.i.FilterOutputStream as this class is sure not even thread-safe. Most
Hi everyone,
Could you please review my change for JDK-8066867?
http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
The task originated from discussion:
2) I would extract the buffer size to a constant as in the NIO Files class
Patrick, we've discussed it already. Correct me if I wrong, but we came to the
conclusion that there's not enough evidence to support the need for this method.
-Pavel
In the transferTo then transferred needs to be a long.
„transferred“ should be a long instead of int
Good catch, guys!
...the method names are inconsistent (the methods in lower case with embedded
underscores)
Fixed. Updated webrev: http://cr.openjdk.java.net/~prappo/8066867/webrev.01/
Apologies Patrick, that's me who misread you. I assume I had a mix of your
reply, our recent conversation and David's question in my head.
About your actual reply. That's probably a matter of taste, since nowhere else
except for this particular method this thing is not used (in
A quick question: can we piggyback on this particular issue and
remove some generics here? (see javac warnings):
diff -r cb475099ceac test/java/util/Collections/EmptyIterator.java
--- a/test/java/util/Collections/EmptyIterator.java Tue Dec 09 09:22:07
2014 -0800
+++
Hi everyone,
Could you please review my change for JDK-8067127?
http://cr.openjdk.java.net/~prappo/8067127/webrev.00/
http://cr.openjdk.java.net/~prappo/8067127/specdiff.00/java/io/package-summary.html
--
The purpose of
...I don't see how this last version is an
improvement. The phrase the number of bytes read is = b.length, in
particular, is jarring since it switches abruptly from prose to symbols;
the original the number of bytes read is, at most, equal to len is far
preferable.
Agreed. And yet
Hi everyone,
Could you please review my change for JDK-8066642?
http://cr.openjdk.java.net/~prappo/8066642/webrev.00/
-Pavel
Hi Patrick, nice to hear from you again! I agree we should consider adding this
method. Unfortunately, from the spec point of view I suppose this one will
require a lot more chewing. For instance there's nothing that can be closed
either in Readable or Appendable (in general case), since neither
Hi everyone,
Could you please review my change for JDK-8067870?
http://cr.openjdk.java.net/~prappo/8067870/webrev.00/
---
I suppose it's the first time this method gets executed. Ever :) There's no need
for a test to be
Updated webrev: http://cr.openjdk.java.net/~prappo/8067870/webrev.01/
Will push as soon as I see test results.
P.S. The thing was lurking there since 28-NOV-2000, ver. 1.106
-Pavel
On 18 Dec 2014, at 14:25, Alan Bateman alan.bate...@oracle.com wrote:
On 18/12/2014 13:32, Pavel Rappo wrote
If I'm not mistaken LinkedList and Vector demonstrate exactly the same buggy
behaviour.
-Pavel
On 7 Jan 2015, at 11:20, Chris Hegarty chris.hega...@oracle.com wrote:
On 07/01/15 10:57, Stanislav Baiduzhyi wrote:
On Wednesday 07 January 2015 10:56:01 Chris Hegarty wrote:
public
Hi everyone,
Could you please review my change for JDK-8075959
http://cr.openjdk.java.net/~prappo/8075959/webrev.00/
-Pavel
Hi,
I've been looking into an old doc issue [1] on incompleteness in description of
handling incorrect arguments in BufferedWriter.write(String, int, int).
In a nutshell it's concerned that given the following facts:
1. Writer.write(String str, int off, int len)
promises to throw
Hi everyone,
Could you please review my change for JDK-8029689
http://cr.openjdk.java.net/~prappo/8029689/webrev.00/
---
There is a long-standing issue when platform implementations of java.io.Reader
throw
Hi Chris,
The spec looks good. The only single detail I've noticed is that the an
exception is thrown as a possible cause of unblocking the method is missing:
--- dev/jdk/src/java.base/share/classes/java/io/InputStream.java (revision )
+++
Hi everyone,
Could you please review my change for JDK-8029804
http://cr.openjdk.java.net/~prappo/8029804/webrev.00/
---
There is an issue where java.io.BufferedWriter.write(String s, int off, int len)
doesn't check
Ivan,
It looks like your change (I don't know whether it was intentional or not)
brings some more fail-fast-ness which is good! For instance, before the
change, this snippet:
ListInteger integers = new LinkedList();
integers.addAll(Arrays.asList(0, 1));
ListInteger sublist =
Hi Patrick,
That's a good idea! I can sponsor them no problem.
-Pavel
On 7 May 2015, at 19:13, Patrick Reinhart patr...@reini.net wrote:
Hi there,
A couple months ago the transferTo() method was added to the JDK. I’m
regularly joining the local hacker garten and wanted to ask if it
Hi Doug,
The reason that flattened forms were not used is that each
layer does not in general know the class of its parent.
Could you please explain this a bit more? I'm afraid I don't quite understand
how this is possible. Thanks.
-Pavel
I’m in a position where I’d need to have a class implement List, but it
already extends something else, so I can’t have it extend AbstractList
Would composition help you instead of inheritance? (I might be missing
something obvious)
-Pavel
(I’ll hand-wave the issue of “protected int modCount” issue for now.)
Not only. Consider this: java.util.AbstractList overrides some methods from
java.lang.Object such as equals and hashCode. And this is a no-no [1]:
...It is a compile-time error if a default method is override-equivalent
will
continue to function as before, but they may need to be updated at some
point in the future.
-Chris.
Best
Lance
On Apr 20, 2015, at 11:10 AM, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi everyone,
Could you please review my change for JDK-8029689
http://cr.openjdk.java.net/~prappo
,
Martijn
On 8 May 2015 at 23:53, Patrick Reinhart patr...@reini.net wrote:
Hi Pavel,
I have changed the most obvious files and made a patch of each repo. I hope
the patches will not be removed…
Cheers
Patrick
Am 07.05.2015 um 20:44 schrieb Pavel Rappo pavel.ra...@oracle.com
The other reason to have read that returns 0 is if the underlying channel
is in non-blocking mode.
A read on an InputStream created by Channels.newInputStream on a
SelectableChannel may return 0
and the code will go in a loop until the SelectableChannel can read
something.
while(read()
So then our transferTo() implementation should be like this?
while ((read = this.read(buffer, 0, TRANSFER_BUFFER_SIZE)) -1) {
Isn't it the same as we have now? :) If you mean 0, then we should probably
wait for someone with both IO and NIO expertise to have a look at this.
Remi,
The other reason to have read that returns 0 is if the underlying channel is
in non-blocking mode.
A read on an InputStream created by Channels.newInputStream on a
SelectableChannel may return 0
and the code will go in a loop until the SelectableChannel can read something.
If you have time it might be useful to have a look for places to retrofit with
java.nio.file.Files This class provides lots of useful tools which cover many
usecases. Especially take a look at `copy` methods. Thanks!
-Pavel
On 12 May 2015, at 23:10, Patrick Reinhart patr...@reini.net wrote:
Any specific implementations can always be added later. As far as I can see, the
spec for `asIterator()` does not specify any identity/state properties of the
returned object.
-Pavel
On 19 May 2015, at 11:41, Tomasz Kowalczewski tomasz.kowalczew...@gmail.com
wrote:
Is there a plan to
Hi Kasper,
I assume your questions are all about WebSocket part, right? If so, then
1)
Would it possible to add a connect timeout parameter.
builder.setConnectTimeout(long timeout, TimeUnit unit)
For some reason it was left out of the javax.websocket API. And working
around it is a
On 3 Aug 2015, at 16:07, Alexander Stepanov alexander.v.stepa...@oracle.com
wrote:
Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
removed wrapping code/code around the links (mostly PrintStream.java,
PrintWriter.java, File.java), plus other
Hi,
While working with an API that extensively uses java.lang.CharSequence, I've
noticed most JDK implementations of CharSequence do not optimize for corner
cases in CharSequence.subSequence(int start, int end). Namely,
1. start == end (an empty subsequence)
2. start == 0 && end ==
Not quite. You don't have the ability to specify a particular implementation
(e.g. the thing won't work if what you want is, say, LinkedList)
On 9 Jul 2015, at 18:34, kedar mhaswade kedar.mhasw...@gmail.com wrote:
Wouldn't Arrays.asList
On 9 Jul 2015, at 18:46, Louis Wasserman lowas...@google.com wrote:
what you can do there is new ArrayList(Arrays.asList(1, 2, 3, 4,
5));
Louis, sure we can do this. No problem with that. But what we are really talking
about here (as far as I understand) is a convenience. In my opinion
Hi,
If anybody is interested in discussing WebSocket client API proposed for JDK 9,
you could participate on net-dev mailing list here:
http://mail.openjdk.java.net/pipermail/net-dev/2015-August/009077.html
I'd be happy to gather as much feedback on it as possible. Thanks.
-Pavel
1 - 100 of 416 matches
Mail list logo
