Looks good.
Rémi
- Mail original -
> De: "jan lahoda"
> À: "Remi Forax"
> Cc: "jonathan gibbons" , "compiler-dev"
> , "build-dev"
>
> Envoyé: Dimanche 6 Mai 2018 20:39:24
> Objet: Re: RFR : JDK-8202387: ja
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 d
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
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:
> http://cr.openjdk.java.net/~gbierman/jep406/j
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:
> http://cr.openjdk.java.net/~gbierman/jep406/j
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:
>> http://cr.openjdk.java.net/~gbierman/j
witches each with its 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 wor
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:
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 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 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:
>> http://cr.openjdk.java.net/~gbierman/j
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:
>> http://cr.openjdk.java.net/~gbierman/je
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 T
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 @
14 matches
Mail list logo
