On 10/9/15 6:11 AM, Stephen Colebourne wrote:
On 9 October 2015 at 00:39, Stuart Marks wrote:
1. Number of fixed arg overloads.
Guava follows this pattern:
of(T)
of(T, T)
of(T, T, T)
of(T, T, T, T... elements)
whereas the proposal has
of(T)
of(T, T)
of(T, T, T)
of(T... elements)
I'd be
On 10/8/15 7:39 PM, Paul Benedict wrote:
I don't think the statements "Creates an unmodifiable set containing X elements"
is always true. Since sets cannot have duplicates, it's possible passing in X
elements gives you less than that based on equality. I think the Set docs should
say "...X poss
On 10/9/15 12:23 PM, Sebastian Sickelmann wrote:
I'll file a bug on the JLS for this.
What is the Bug-Number. Maybe i can watch and comment on this.
https://bugs.openjdk.java.net/browse/JDK-8139324
s'marks
On 10/9/15 11:54 AM, Chris Hegarty wrote:
On 9 Oct 2015, at 19:51, Stuart Marks wrote:
Dr Deprecator approves!
Hmmm.. does Dr Deprecator have an OpenJDK userId? If not, we should
have one assigned! ;-)
Yes, good idea. At some point, then, Dr Deprecator will become a Decommitter.
On Oct 8, 2015, at 11:56 PM, Gil Tene wrote:
>
>>
>> On Oct 8, 2015, at 6:18 PM, John Rose wrote:
>>
>> On Oct 8, 2015, at 12:39 AM, Gil Tene wrote:
> … If/when MONITOR/MWAIT becomes available in user mode, it will join ARM v8
> and SPARC M7 in a common useful paradigm.
>
>> Also, from a cr
On 10/09/2015 12:37 PM, Alan Bateman wrote:
On 09/10/2015 20:26, Jim Laskey (Oracle) wrote:
"it should never attempt to use the native implementation” This is
confusing. It’s attempting to see if a native library is present
otherwise use java. Is this the wrong approach?
jrtfs should use
Hello,
Please, review the fix for schemagen regression bug [1] in JDK9: The
JDK9 (and JDK8 too) version of schemagen doesn't report errors during
the compilation of the input java file.
The issue was introduced by standalone JAXB project changes and then it
was synced to JDK source. The Schema
On 09/10/2015 20:43, Jim Laskey (Oracle) wrote:
I’m still missing something. How does the jrtfs code ‘know’ it’s in a jar vs
part of the jdk9 runtime?
In jrtfs then SystemImages has code to look at its code source.
-Alan.
Hi,
I have updated the materials for the first prototype of
JEP 264 - Platform Logging API and Service.
I have done some minor editorial changes in the API doc
( null -> {@code null} ) fixed a few minor issues,
and added some new tests. Sandbox has been updated.
JEP:
http://openjdk.java.net/jep
I’m still missing something. How does the jrtfs code ‘know’ it’s in a jar vs
part of the jdk9 runtime?
> On Oct 9, 2015, at 4:37 PM, Alan Bateman wrote:
>
>
> On 09/10/2015 20:33, Chris Hegarty wrote:
>> On 9 Oct 2015, at 20:26, Alan Bateman wrote:
>>
>>> I looked more closely at this and
On 09/10/2015 20:33, Chris Hegarty wrote:
On 9 Oct 2015, at 20:26, Alan Bateman wrote:
I looked more closely at this and I think it's best to handle NCDFE rather than
the more general LinkageError.
Ok, I make the follow change before pushing:
diff --git
a/src/java.base/share/classes/jdk/i
On 09/10/2015 20:26, Jim Laskey (Oracle) wrote:
"it should never attempt to use the native implementation” This is confusing.
It’s attempting to see if a native library is present otherwise use java. Is this
the wrong approach?
jrtfs should use the native implementation when targeting the
On 9 Oct 2015, at 20:26, Alan Bateman wrote:
> I looked more closely at this and I think it's best to handle NCDFE rather
> than the more general LinkageError.
Ok, I make the follow change before pushing:
diff --git
a/src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
b/s
"it should never attempt to use the native implementation” This is confusing.
It’s attempting to see if a native library is present otherwise use java. Is
this the wrong approach?
> On Oct 9, 2015, at 4:18 PM, Alan Bateman wrote:
>
> On 09/10/2015 19:59, Chris Hegarty wrote:
>> This is a
I looked more closely at this and I think it's best to handle NCDFE
rather than the more general LinkageError. But I hope very temporary, we
need to get this code fixed so do the right thing.
-Alan
On 10/09/2015 08:58 PM, Stuart Marks wrote:
> On 10/9/15 4:16 AM, Aleksey Shipilev wrote:
>> Please note that "static final Boolean myBool = new
>> Boolean(true).booleanValue()" is a spec-recommended way to avoid binary
>> incompatibilities caused by conditional compilation. See JLS 13.4.9.
>> Ther
On 09/10/2015 19:59, Chris Hegarty wrote:
This is a little temporary solution to get the jrt-fs up and running again
with JDK 8, until JDK-8137017 [1] can be resolved.
It is fair game for an unchecked Exception or Error thrown during
class initialization to result in a NCDFE. The code in BasicIm
My point, and Daniel's point, is that requireNonNull can be re-interpreted
(ret-conned) as enforcing a post-condition instead of a pre-condition. (The
logic of JDK 8 rNN allows either view equally.) Then all of these API points
hang together very nicely.
After I tinkered with the cross-simula
On 10/9/15 4:16 AM, Aleksey Shipilev wrote:
Please note that "static final Boolean myBool = new
Boolean(true).booleanValue()" is a spec-recommended way to avoid binary
incompatibilities caused by conditional compilation. See JLS 13.4.9.
Therefore, deprecating Boolean constructors is a spec issue
This is a little temporary solution to get the jrt-fs up and running again
with JDK 8, until JDK-8137017 [1] can be resolved.
It is fair game for an unchecked Exception or Error thrown during
class initialization to result in a NCDFE. The code in BasicImageReader
should catch java.lang.LinkageErr
+1
Mandy
P.S. These two classes do not show up in the list of JDK internal API
referenced I gathered.
On 10/09/2015 10:23 AM, Chris Hegarty wrote:
The functionality provided by these classes has long since been provided
by supported APIs in java.util.concurrent.locks. Nothing internal, or ex
On 9 Oct 2015, at 19:51, Stuart Marks wrote:
> On 10/9/15 10:23 AM, Chris Hegarty wrote:
>> The functionality provided by these classes has long since been provided
>> by supported APIs in java.util.concurrent.locks. Nothing internal, or
>> external
>> ( to the best of my knowledge ), to the JDK
On 10/9/15 10:23 AM, Chris Hegarty wrote:
The functionality provided by these classes has long since been provided
by supported APIs in java.util.concurrent.locks. Nothing internal, or external
( to the best of my knowledge ), to the JDK is depending on these classes.
They should simply be remove
If I ever knew about these classes, I have long forgotten!
On Fri, Oct 9, 2015 at 10:23 AM, Chris Hegarty
wrote:
> The functionality provided by these classes has long since been provided
> by supported APIs in java.util.concurrent.locks. Nothing internal, or
> external
> ( to the best of my kno
On 09/10/2015 18:23, Chris Hegarty wrote:
The functionality provided by these classes has long since been provided
by supported APIs in java.util.concurrent.locks. Nothing internal, or external
( to the best of my knowledge ), to the JDK is depending on these classes.
They should simply be remo
On 10/09/2015 08:23 PM, Chris Hegarty wrote:
> The functionality provided by these classes has long since been provided
> by supported APIs in java.util.concurrent.locks. Nothing internal, or
> external
> ( to the best of my knowledge ), to the JDK is depending on these classes.
> They should s
Agree a webrev would be silly.
Trust you on this and +1
Best
Lance
On Oct 9, 2015, at 1:23 PM, Chris Hegarty wrote:
> The functionality provided by these classes has long since been provided
> by supported APIs in java.util.concurrent.locks. Nothing internal, or
> external
> ( to the best of
The functionality provided by these classes has long since been provided
by supported APIs in java.util.concurrent.locks. Nothing internal, or external
( to the best of my knowledge ), to the JDK is depending on these classes.
They should simply be removed.
$ hg rm src/java.base/share/classes/
Hi,
The primary purpose of the existing 'requireNonNull' methods is to check
for null
and throw an exception. It is used for explicit testing and producing a
cogent exception.
Returning the value was a secondary benefit that allowed it to be used
in fluent expressions.
The purpose of the new
On 09/10/15 13:08, Peter Levart wrote:
Hi,
On 10/09/2015 04:39 AM, Paul Benedict wrote:
I don't think the statements "Creates an unmodifiable set containing X
elements" is always true. Since sets cannot have duplicates, it's
possible
passing in X elements gives you less than that based on equal
On 9 October 2015 at 00:39, Stuart Marks wrote:
> 1. Number of fixed arg overloads.
Guava follows this pattern:
of(T)
of(T, T)
of(T, T, T)
of(T, T, T, T... elements)
whereas the proposal has
of(T)
of(T, T)
of(T, T, T)
of(T... elements)
I'd be interested to know why Guava did it that way and w
Hi Brian,
On 09/10/15 13:41, Brian Goetz wrote:
The semantics of require* here was that it should throw if the precondition
is violated. That lead to a different naming direction than the current
use case, in which null is an expected value rather than an error.
Not necessarily - as the requi
Hi,
On 10/09/2015 04:39 AM, Paul Benedict wrote:
I don't think the statements "Creates an unmodifiable set containing X
elements" is always true. Since sets cannot have duplicates, it's possible
passing in X elements gives you less than that based on equality. I think
the Set docs should say "..
The semantics of require* here was that it should throw if the precondition is
violated. That lead to a different naming direction than the current use case,
in which null is an expected value rather than an error.
Sent from my iPhone
> On Oct 9, 2015, at 11:58 AM, Stephen Colebourne wrote:
On 10/08/2015 09:58 PM, Stuart Marks wrote:
> On 10/7/15 12:59 PM, Sebastian Sickelmann wrote:
>> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/
>>
>> jdk:
>> The Boolean constructors are @Deprecated now so that we get
>> compile-warnings for the uses. See also [0] and [1]
>>
>>
On 9 October 2015 at 01:31, John Rose wrote:
> This leads me to yet another bikeshed color, FWIW:
>
> - T requireNonNull(T) (cf. Optional::get)
> - T requireNonNullElse(T,T) (cf. Optional::orElse)
> - T requireNonNullElseGet(T,Supplier) (cf. Optional::orElseGet)
> - T requireNonNullElseThrow(T
On 10/08/2015 08:58 PM, Stuart Marks wrote:
> On 10/7/15 12:59 PM, Sebastian Sickelmann wrote:
>> http://cr.openjdk.java.net/~sebastian/5108778/core-libs/webrev.00/
>>
>> jdk:
>> The Boolean constructors are @Deprecated now so that we get
>> compile-warnings for the uses. See also [0] and [1]
>>
>>
> On 9 Oct 2015, at 02:31, John Rose wrote:
>
> It may be instructive to link nulls to Optionals by encoding null-ness using
> Optional:
>
> T nonNullElse(T x, T y) := Optional.ofNullable(x).orElseGet(() ->
> Optional.ofNullable(y).get())
>
And with the new Optional.or [*] to be added soon
38 matches
Mail list logo
