On Fri, 4 Jun 2021 20:20:26 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>>
On Wed, 26 May 2021 17:52:36 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>>
On Tue, 25 May 2021 16:14:56 GMT, Jan Lahoda wrote:
> I'd like to note this is a preview feature - we can change the desugaring. At
> the same time, I don't think this does not work with sub-patterns (those can
> be easily desugared to guards, I think).
Yes, but in that case the classcheck du
On Tue, 25 May 2021 14:22:57 GMT, Jan Lahoda wrote:
> The reason for this integer (which is not a constant in the case of this
> switch) is to restart the matching in case guards fail to "match".
> Considering the example here:
>
> ```
> class Example {
> void example(Object o) {
>
On Tue, 25 May 2021 12:20:02 GMT, Jan Lahoda wrote:
> Thanks Evgeny, I'll take a look.
>
> @forax, do you mean why there is "0" in:
> 11: invokedynamic #13, 0
> ?
Not this one, the one on the stack.
7: iconst_0 < this zero
8: istore_3
9: aload_2
10: iloa
s own little twist
>>> attached to it. It would be nice, I think (maybe in a separate cleanup?) if
>>> the
>>> code paths serving the different switch kinds could be made more separate,
>>> so
>>> that, when reading the code we can worry only about one po
On Mon, 17 May 2021 19:04:11 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>>
On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote:
> This is a preview of a patch implementing JEP 406: Pattern Matching for
> switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> The current draft of the specification is here:
>
On Tue, 4 May 2021 16:41:44 GMT, Jan Lahoda wrote:
> This is a preview of a patch implementing JEP 406: Pattern Matching for
> switch (Preview):
> https://bugs.openjdk.java.net/browse/JDK-8213076
>
> The current draft of the specification is here:
>
On Wed, 18 Nov 2020 13:45:46 GMT, Jim Laskey wrote:
>> Need rebase
>
> Created new PR because of forced push:
> https://github.com/openjdk/jdk/pull/1292
LGTM
-
PR: https://git.openjdk.java.net/jdk/pull/1273
An honest question,
why do we need so many interfaces for the different categories of
RandomGenerator ?
My fear is that we are encoding the state of our knowledge of the different
kinds of random generators now so it will not be pretty in the future when new
categories of random generator are
Hi Magnus,
please try not to use @SuppressWarnings("unchecked") on methods, but on local
variable instead to reduce the scope,
you can introduce a local variable for that.
In Bundle, your patch declare @SuppressWarnings("unchecked") on the method
while you already have a local variable with a
Looks good.
Rémi
- Mail original -
> De: "jan lahoda" <jan.lah...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "jonathan gibbons" <jonathan.gibb...@oracle.com>, "compiler-dev"
> <compiler-...@openjdk.j
Hi Jan,
there is several occurences of Arrays.asList() that can be replaced by
List.of() to make them really immutable.
in CreateSymbols.java
in dumpCurrentClasses,
while ((read = in.read()) != (-1)) {
baos.write(read);
}
should be replaced by
in.transferTo(baos);
in
14 matches
Mail list logo
