past reference type patterns” in the amber-spec-experts mailing list
of April 2022 don’t even mention the mixed integral/floating-point case.
Greetings
Raffaello
*From: *core-libs-dev on behalf
of Brian Goetz
*Date: *Tuesday, 24 May 2022 at 00:09
*To: *Raffaello Giulietti ,
core-libs-dev
Themotivation behind this PR isnot driven by pattern matching:John
Rose (the reporter of the JBS issue) is concerned about having safer
casts that, in addition, can be JITted to efficient code.
Yes, of course. But also, as the platform evolves, it often happens
that the same issues
This work is quite timely as we are now paving the way for primitive
type patterns over in Project Amber, and also has a nontrivial
connection with Valhalla. If you'll pardon a brief digression...
Instanceof and casting work together in a familiar way: before you cast,
you first ask
This is a nice use of `mapMulti` to create a stream whose contents are
dynamically generated. It is one step short of generators (which we
hope Loom will eventually give us), in that it is restricted to a
generator method that generates all of the elements in one invocation.
This is still
MethodType is a useful shape for describing a pattern, in reverse; the
“parameter” types are really the pattern bindings, and the “return” type is
really the (minimal) type of the target. With such a description, the
MethodType for a pattern is the right input to get the carrier for the
It is a base assumption that the specific representation — bits in an int[], a
class per shape, a cache of common shapes, etc — is a pure implementation
detail that can be changed at will, based on various tradeoffs like
footprint-vs-startup that can be made at any time. The only assumption is
You keep saying “what we need”. But really, what I think you mean is “what the
scheme I have in mind needs.” Can we try and separate these out? I don’t
think any of these are *needed*, but maybe you want to make the argument that
you have a better scheme in mind, and we should choose that
Yes, and ...
There are words of flags elsewhere scattered through the JDK, such the
InnerClasses attribute, module flags in the Module attribute, and flags
on the "requires" entries in the Module attribute. Having one
abstraction to cover all these locations, even though reflection doesn't
It's a time-honored tradition in naming bikesheds to pick and choose the
precedents you want to be "consistent" with, and I think that's what's
going on here with your preference for "Ordered" over "Sequenced". But
in an ecosystem as large as Java, you can always find conflicting
precedents
Are you proposing dropping SIZED from the spliterator for arrays? This
would undermine all the array-based optimizations (e.g., toArray), which
seems a bad trade. I realize the splitting heuristics are frustrating
for a number of use cases, but this seems like throwing the baby out
with the
As the language currently stands, new means new; it is guaranteed to create a
new identity. (When Valhalla comes along, instances of certain classes will be
identity-free, so the meaning of new will change somewhat, but String seems
likely to stay as it is.)
The language is allowed (in some
I don’t see how a restricted reference by itself is useful, if you cannot
depend upon the object not being mutated via other references.
Agree; this may help you do local proofs of correctness, and may conceivably
help the JIT (though, its pretty smart about figuring this stuff out on its
While I'm the first to admit that the design of annotations incorporated
a great deal of optimism about its sufficiency, I think the
return-on-complexity for such things is not good enough to warrant
working on this.
Now I was thinking: wouldn't it be nice to be able to define a custom
I would suggest that we hold this patch until the string interpolation
JEP lands. It will offer both better readability *and* better
performance, and probably better to have one round of "replace all the
toString implementations" than two?
On 11/10/2021 1:04 PM, Eamonn McManus wrote:
Use
I am not really sure we’ve gotten the right idiom here yet. I’d like to slow
down a bit before making an API decision.
What id suggest is capturing the proposed api and spec on list, and let’s let
this sit and bake for a bit longer. My sense is that something better may well
emerge if we
In Java 8, I think we were reluctant to lean on the idiom of "pass me a
lambda and I'll pass it the confined data"), because Java developers
were already struggling to understand lambdas. But now that we're
mostly over that hurdle, API points that accept Consumer are
a powerful way to gain
);
requireNonNull(names);
requireNonNull(getters);
On 8/23/2021 4:04 PM, Brian Goetz wrote:
+1
On 8/23/2021 2:22 PM, Vicente Romero wrote:
Please review this simple PR along with the associated CSR. The PR is
basically adding a line the the specification of method
`java.lang.runtime.ObjectMethods
+1
On 8/23/2021 2:22 PM, Vicente Romero wrote:
Please review this simple PR along with the associated CSR. The PR is basically
adding a line the the specification of method
`java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a
NPE will be thrown.
TIA
link to the
This was an early attempt at the functionality provided by LambdaMetafactory.
It could probably be reimplemented on top of that, but probably could be
deprecated in favor of LMF as well.
Sent from my iPad
> On Aug 22, 2021, at 10:08 PM, liangchenb...@gmail.com wrote:
>
> Currently,
For the third time: This discussion illustrates why the PR was
premature; the design was not agreed upon first. High-level design
discussions (i.e., "is this a good design", "is this a good idea at
all", "are we solving the right problem", "does it need to be solved in
the JDK") should happen
On Mon, 9 Aug 2021 12:28:23 GMT, CC007
wrote:
> create Streamable and ParallelStreamable interface and use them in Collection
> and Optional
To reiterate: These issues were explored in the JSR 335 EG and it was agreed
that this abstraction did not carry its weight. In any case, it is
On Mon, 9 Aug 2021 12:28:23 GMT, CC007
wrote:
> create Streamable and ParallelStreamable interface and use them in Collection
> and Optional
I understand what you are proposing. I do not believe Streamable carries its
weight.
Sent from my iPad
> On Aug 14, 2021, at 8:53 PM, CC007
On Mon, 9 Aug 2021 12:28:23 GMT, CC007
wrote:
> create Streamable and ParallelStreamable interface and use them in Collection
> and Optional
I object to this change. These issues were explored in the JSR 335 EG and it
was agreed that this abstraction did not carry its weight. In any case,
Starting with a PR is not the way to add significant API surface to the JDK.
You have to first build consensus on the mailing list for the design concept
before we start talking about code.
FTR, Interfaces like these were already discussed and rejected in the JSR 335
design discussions.
You might also consider bringing this to panama-dev, since that will
eventually be the recommended replacement for most uses of JNI.
On 7/21/2021 6:25 PM, David Holmes wrote:
Hi Hans,
On 22/07/2021 7:54 am, Hans Boehm wrote:
Is this an appropriate list to discuss JNI?
No - hotspot-dev (to
Bootstrap methods are cheap. If you have one that is semantically
different, better to write a separate bootstrap than to try and cram two
sets of functionality into one. So +1 for "make a new bootstrap for enums."
On 6/16/2021 11:25 AM, Jan Lahoda wrote:
Currently, an enum switch with
On 6/7/2021 5:51 AM, Remi Forax wrote:
Hi all,
the first part of the message is about javac error message that could be
improved,
the second part is about the current spec being not very logical.
With this code
Object o = null;
var value = switch(o) {
//case null -> 0;
It seems pretty clear that this "feature" is a leftover from an early
implementation, doesn't clearly say what it is supposed to do, is more
complicated than it looks, and is buggily implemented. While I
understand the temptation to "fix" it, at this point we'd realistically
be adding a
The motivation here is that we wanted to preserve the ability to
describe "special" indy sites with special objects. The standard
implementation can describe any indy site (bootstrap, static args,
invocation name and type), but some indy sites (e.g., lambda capture)
are "special". It would
Since the discussion happened over the holiday weekend, I didn't get a
chance to respond until now, but I think that this came to a good
outcome. As Alan's archaeology discovered, this flag appears to be a
leftover from the original implementation, and I could find no signs of
its usage. We
On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote:
>> Inspired by PR#4088. Most of the changes are done automatically using
>> IntelliJ IDEA refactoring. Some manual adjustments are also performed,
>> including indentations, moving comments, extracting common cast out of
>> switch
On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote:
>> Inspired by PR#4088. Most of the changes are done automatically using
>> IntelliJ IDEA refactoring. Some manual adjustments are also performed,
>> including indentations, moving comments, extracting common cast out of
>> switch
In the last hunk, you convert
case Collator.IDENTICAL: toAddTo.append('='); break;
case Collator.TERTIARY: toAddTo.append(','); break;
case Collator.SECONDARY: toAddTo.append(';'); break;
case Collator.PRIMARY: toAddTo.append('<'); break;
case RESET:
rstood Brian, great answer.
>
> Could you please answer to my other proposal?:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077955.html
>
> Regards,
>
> Alberto.
> ________
> De: Brian Goetz
> Enviado: sábado, 22 de mayo de
There is no end to patterns of code that could be generated by tools, and for
each of them, one can imagine situations where they would be useful. But in
addition to the other reply about how builders are really only called for when
there are a large number of _optional_ components, the
Has it ever been conceived to create an entire new API like how it was
done for Dates and Times? Obviously this would be a massive
undertaking, but it seems to me we've just about reached the limits of
how far we can stretch the current API.
"This code is a mess, we should throw it away and
Let's try again: why is that important? What decisions would you
make differently if you had this information? What benefit would
come from those decisions?
Threading is hard.
Gee, thanks MIke for pointing that out to me, obviously I'm new to the
topic :)
Scoped variables
Let's back up a lot of steps; you're deep in proposing a solution
when you've not even explained what problem you think you're
solving. So control question, which I hope will start to expose
the assumptions:
Why do you think its important to know that a snapshot of a
How so? How do I know if a snapshot of my variable has occurred?
Let's back up a lot of steps; you're deep in proposing a solution when
you've not even explained what problem you think you're solving. So
control question, which I hope will start to expose the assumptions:
Why do you
The lifecycle is bounded by the duration of the Runnable passed to the
`run()` method.
In the simple case, with no inheritance and no snapshotting:
ScopedLocal.where(x, xExpr).run(r)
the lifecycle of the binding starts when we enter r, and ends when we
return from r.
With snapshotting,
Its simpler than you're making it. Think of the motivating use cases
for ThreadLocal, such as when a container calls into user code, and the
user code calls back into the container, and we need to keep track of
{transaction, security, etc} context, and it is impractical to pass them
all
is
still valid (I haven't found any of such test though).
Mandy
On 5/11/21 6:20 AM, Brian Goetz wrote:
There may be some JDK code that checks for anon classes by comparing the name
to see if it contains a slash, especially tests, but which don’t say
“anonymous”. Did you do a search
Scope locals have come together nicely.
I have some vague thoughts on the presentation of the JEP draft. There
are (at least) three intertwined things in the motivation:
- ThreadLocal (and ITL especially) were always compromises, and with
the advent of Loom, have become untenable -- but
Yes, please!
To add to the list of motivations/things to remove: the current
implementation relies on the special `MagicAccessorImpl` to relax
accessibility. The notes in this class are frightening; getting rid of
it would be a mercy.
On 5/11/2021 4:42 PM, Mandy Chung wrote:
This draft
There may be some JDK code that checks for anon classes by comparing the name
to see if it contains a slash, especially tests, but which don’t say
“anonymous”. Did you do a search for these idioms too, which are now dead
tests?
Sent from my iPad
> On May 11, 2021, at 8:59 AM, Harold Seigel
Yes, this has been considered at some length. The summary verdict is:
- Method references for static/unbound methods seem like reasonable
constant literals to put in annotations, not unlike class literals.
- Lambdas, on the other hand: absolutely, positively, not.
To actually get to method
While I agree that we should be careful, let's not paint ourselves into
an either/or strawman. The choice is not "never add anything to
Collection" vs "let's dump every silly idea that comes to anyone's mind
into Collection"; it is, as always, going to involve tradeoffs between
stability and
This is basically Spliterator, an iterator + a size, with the iterator is "push" instead
of "pull" because it's more efficient.
In details a Spliterator is either
- an Iterable (with no SIZED characteristic)
- an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE)
- an Iterable +
Is there a compelling example of where this would be used by clients?
Here are some examples:
https://stackoverflow.com/questions/10988634/java-global-isempty-method
Without passing judgment on the sort of dynamically typed programs that
need a method like this, or wondering what
This has come up before. For example, during an early iteration of the
Stream design, before parallelism entered the picture. The first
scrawled-on-a-napkin prototype for streams was based on Iterator, and it
took about a minute to realize that we could do a much better job if we
had a
Adding a REVERSIBLE characteristic to spliterators is easy enough, and
as you say, many useful sources can easily provide an efficient reverse
operation. Filtering and mapping can preserve reversibility. The real
question is what to do if someone calls reverse() on a non-reversible
stream.
Project Valhalla will allow Instant to be migrated to a primitive class,
which would address your problem.
On 4/2/2021 7:47 PM, Ralph Goers wrote:
Log4j 2 supports the notion of a PreciseClock - one that can be initialized to
something more precise than a millisecond. At the same time it also
They'll find a natural home in JDBC, since SQL has a native decimal type.
On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:
As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and
Overall, I'd be happy to see Decimal types that are aimed at "reasonable
precision" in addition to the infinite precision that BD offers. (After
Valhalla, of course.)
On 3/29/2021 4:14 PM, Raffaello Giulietti wrote:
Hello,
I'm experimenting with an implementation of Decimal64 and
These patches are obviously minimally correct. However, for equals
methods at least, I would take them one step further, from:
if (!(o instanceof Key that)) return false;
//noinspection StringEquality (guaranteed interned String(s))
return name == that.name
Looks good! Glad to see the Amber features finding their way into the
codebase.
On 3/8/2021 1:53 PM, Patrick Concannon wrote:
Hi,
Could someone please review my code for updating the code in the `java.io`,
`java.math`, and `java.text` packages to make use of the `instanceof` pattern
I have been reading previous threads, the original bug request, and exploring
the javadoc and implementation of toList() on Stream in JDK 16. I don’t want to
waste time rehashing previous discussions, but I want to understand and
prioritize the motivation of this change, and propose what I
On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
But after thinking about it, I'm now convinced that it would be a bad
idea. Because it extends the scope of this small, tiny Iterable
interface to something bigger which it shouldn't be.
This response captures the essence of the problem. You
I wonder if we should not do the same with toList(), having toList() to be equivalent to
collect(Collectors.toUnmodifiableList()) and toList(IntFunction>)
allowing to use a null friendly List implementation like ArrayList.
If you pull on this string all the way, we end up with "let's just
As for nullity topic, I really welcome that the proposed toList() is
null-tolerant but it worth mentioning that existing terminal
operations like findFirst(), findAny(), min() and max() are already
null-hostile.
The min() and max() methods are not null hostile. If you pass a
null-friendly
There is no value in making users remember which stream methods are
null-hostile and which are null-tolerant; this is just more accidental
complexity.
I think that ship has sailed a long ago.
Some collectors are null hostile, some are not.
You can make a point that a Collector is technically
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 Stream enables it to do what can't easily by done by a
Minor nit:
Appendable foo(Appendable bar)
should be
A foo(A bar)
That way, if you say
hex.formatHex(aStringBuilder, bytes)
.foo()
where foo() is a method on StringBuilder but not on Appendable, it will
still work as expected.
On 9/28/2020 11:32 AM, Roger Riggs wrote:
Should this patch be a workaround to existing releases rather than
the main line? As Brian mentions, lambda proxy class may become
inline class in valhalla repo (Roger has a patch already). The
earlier fixing those programs the better.
Indeed if we know this is landing in this cycle
So from your (and Alan's and Lance's) point of view does it still make
sense to create a JEP for this enhancement and have a broader
discussion about its usefulness on the "discuss" list? Or is your
rejection definitive, no matter what the outcome of such a discussion
will be?
I think
On 7/24/2020 7:48 AM, Volker Simonis wrote:
I think it's reasonable to ask if the JDK
really needs to support this complexity.
I can't see much complexity here.
Then I think we should start there. Until you can see the complexity
here that is obvious to Alan, Lance, myself, and others,
On 6/24/2020 7:32 PM, Remi Forax wrote:
I don't really like the name "mapMulti", because flatMap can also be called
mapMulti.
Public service announcement: remember just how frustrating it is for
Patrick to have put in all this work and get only comments like "I don't
like the name."
If
Consider a ClassValue for this, if there is not an obvious bit to be
repurposed somewhere.
On 6/23/2020 12:30 PM, Chris Hegarty wrote:
I think it is worth considering caching the record-ness state of a j.l.Class,
as I’m sure it will be widely used in third-party serialization libraries, as
On 6/23/2020 2:08 PM, Gilles Duboscq wrote:
In 8232806, a system property was introduce to disable eager initialization of
the classes generated by the InnerClassLambdaMetafactory
(`jdk.internal.lambda.disableEagerInitialization`).
However, when `disableEagerInitialization` is true, even
Without commenting on the merits of the proposal, let me point out that asking
for a sponsor at this point is skipping many important steps.
I would recommend you focus first on *building consensus* that (a) there is a
problem, (b) you have identified the correct problem, (c) it is a problem
Overall, the approach seems sound, and I like that you are introducing only one
new bootstrap that is usable for a range of things. A few comments and
questions.
1. Not sure the explicit source type carries its weight, but whether it does
or not is probably informed by whatever we do for
nly proxy interfaces), the interesting access control is done on the
class lookup. This would result in similar costs for looking up the
Method, but delaying it to first use (still paying the one-by-one condy
dispatch vs doing them all as a group in .)
On 11/23/2019 5:54 PM, Johannes Kuhn wrote:
On 11/23/
Finally, we can benchmark the current approach against the LDC
approach on a per-Method basis. The LDC approach may well be doing
more work per Method, so it's a tradeoff to determine whether
deferring that work is a win.
By this last bit, I mean JMH'ing:
Method m1() {
I just finished the first prototype, which can be found at
https://gist.github.com/DasBrain/7766bedfbc8b76ba6a0ee66a54ba97ed - it
contains a patch, the javap output of a generated proxy class with and
without that patch, and the code I used to dump the proxy class. "make
run-test-tier1"
t espace. So, again, doing it by hand this time.
>
> On 22.11.2019 20:52, Brian Goetz wrote:
> > For those that are not intimately familiar with the mechanics of proxy
> > class generation, it would be great to flesh this out with a code example,
> > that shows the proposed
For those that are not intimately familiar with the mechanics of proxy
class generation, it would be great to flesh this out with a code
example, that shows the proposed old and new translation. This would
make it easier for folks to evaluate the benefits and costs of the
approach, and
https://github.com/graalvm/labs-openjdk-11/commit/00b9ecd85dedd0411837eee33635dd83e8b7def8
and initializes them with Unsafe as an optimization
https://github.com/graalvm/labs-openjdk-11/commit/273e8590a7b57c0c10d9213ca9e0ba581e2817b8
After the discussion with Brian Goetz, we have trimmed
ion of string concatenation expressions
>> because of bootstraping issues.
>>
>> If your benchmarks bellow are compiled with option
>> -XDstringConcat=inline to disable JEP280 translation (as java.base
>> module is), then it's OK. E
There's another reason to avoid these writes, besides CDS optimizations:
do-nothing writes generate useless card mark activity.
On 4/1/2019 7:57 AM, Claes Redestad wrote:
Hi,
when a String has a calculated hash code value of 0, we recalculate and
store a 0 to the String.hash field every time
+1 from me.
http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/
AbstractValidatingLMF
-
I see you renamed most of the fields and params. Most of these are
improvements, but it may be worth being more explicit in ambiguous
cases. For example, there are two method
My fear is more than we will want in the future to have one code for all kinds of Stream, but
Stream will have to implement Iterable while Stream will
not, this not something you can actually do with the current generics, we may be able to do that
with the reified generics but some
> A new concern from me is that this change would allow Iterable and
> Stream to be used in foreach, but not Iterator. This seems like an
> odd/sharp conceptual edge.
Not actually a new concern — this was discussed back in JSR 335 as well.
> Why not make `Iterator` implement `IterableOnce`?
It think this alternative is not given fair comparison. 1st this is an
instance method, so the foreach loop should read:
for (T t : stream.asIterable()) {
...
}
Let's keep sight of the goal here, which is: people find it a gap that
Stream does not play cleanly with foreach. And the
Due to how Iterable is specified now it does not promise multiple
iterations, but due to how most (all that I know of except
DirectoryStream or some 3rd party) Iterables are implemented now, the
common expectation is that it does. By implementing more Iterable(s)
that don't support
No. You have the LSP backwards (though this is easy to do.)
IterableOnce means "*must throw* on subsequent use"; under this spec, an
arbitrary Iterable is most certainly *not* an IterableOnce, and
therefore an LSP violation.
It sounds like you are suggesting that we instead spec
On 3/8/2019 3:47 PM, Lukas Eder wrote:
Hello,
I've recently learned about JDK 12's new String::transform method:
https://bugs.openjdk.java.net/browse/JDK-8203703
Obviously, this is useful. And obviously, this would be far more useful as
a general pattern than just something for String. E.g.
So, unfortunately I think this particular API evolution idiom is kind of
questionable. There is a new method, sizedSupplier, with a default that
delegates to the unsized supplier. But, that leaves implementors in a position
where they don’t really know which one to implement, and the use of
We did consider this problem when designing the Collector API; for
example, it would have been nice if we could have a `toArray()`
collector that had all the optimizations of `Stream::toArray`.
When we looked into it, we found a number of concerning details that
caused us to turn back (many
This is a very nice patch, complete with spec and tests, and evidence of
OCA.
But, before we talk about patches and code, let's step back and talk
about stewardship. With API proposals, we like to start with problems,
rather than solutions: what problems we are concerned with, and are
these
/29/19 9:52 PM, Brian Goetz wrote:
How is this different from Collectors.collectingAndThen?
Hi Brian,
It is exactly the same!
I'm sorry, I haven discovered that method when I needed it. Perhaps I
was looking for another name?
Regards, Peter
On 1/29/2019 3:30 PM, Peter Levart wrote:
Hi
How is this different from Collectors.collectingAndThen?
On 1/29/2019 3:30 PM, Peter Levart wrote:
Hi,
I wonder if there's any interest in adding a convenience factory
method for a Collector to the standard repertoire which would look
like the following:
/**
* Convert given {@link
> Hi Alan/Brian,
My apologies for having missed this the first time around; messages to lists
get swept into folders, and staying on top of many lists is not an exact
science.
> I believe I have addressed all outstanding comments on the JEP per se,
> including those made by Alan. Is it now
+1 from me.
On 1/7/2019 1:17 PM, Vicente Romero wrote:
I have updated the webrev after additional feedback from the TCK
tester please check last version at [1]
Thanks,
Vicente
[1] http://cr.openjdk.java.net/~vromero/8215510/webrev.01
On 1/3/19 12:21 PM, Vicente Romero wrote:
Please review
implementation is that
inefficient (in case
you only want to get a nullable value)?
Brian Goetz hat am 8. Januar 2019 um 16:57 geschrieben:
Here's a default implementation that returns the actual key:
default Optional> getEntry(K key) {
for (Map.Entry e : entry
the following is possible:
m1.getKey(k2) == k2 // true
m2.getKey(k2) == k2 // false
Brian Goetz hat am 7. Januar 2019 um 00:54 geschrieben:
FYI, the comment about compatibility was obsoleted by the addition of
default methods in Java 8.
Followers of Project Valhalla will see that this issue comes up when
defining equality on value types. The relation you are looking for is
being called "substitutible"; it asks whether there is any way to
distinguish between two values. For primitives other than float/double,
this coincides
FYI, the comment about compatibility was obsoleted by the addition of
default methods in Java 8.
On 1/4/2019 6:34 PM, some-java-user-99206970363698485...@vodafonemail.de
wrote:
The methods currently provided by the Map interface
(https://docs.oracle.com/javase/8/docs/api/java/util/Map.html)
For Map, you can do:
for (Map.Entry e : map.entrySet()) { ... }
and you're already there.
On 12/19/2018 9:54 AM, Alan Snyder wrote:
Has any consideration been given to supporting iterators that provide more than
one iteration variable in the enhanced for loop?
Obvious uses would be
+1 from me.
Appears that it covers all the issues that were raised in the CSR and by JCK
since integration.
> On Dec 13, 2018, at 10:14 AM, Vicente Romero
> wrote:
>
> Hi all,
>
> I have provided another iteration to the webrev at [1]. This one includes
> additional changes to make sure
You say it jokingly, but we've explored this. (The exact way you phrase
it (the supertype specified to throw if called more than once) means
that Iterable can't extend IterableOnce, because then Iterable does not
conform to the superclass contract, but there are other ways to stack
it.) It's
1 - 100 of 299 matches
Mail list logo
