On 2019-02-15 04:31, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Moved native code under platform specific folder.
- Removed most usage on #ifdefs for WINDOWS,
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch branch of the open sandbox
repository (jpackage).
- Moved native code under platform specific folder.
- Removed most usage on #ifdefs for WINDOWS, LINUX, MAC and POSIX.
- MAC define is still used in
On 2/14/19 12:39 PM, Daniel Fuchs wrote:
Let me redo my fix and see if the JCK complains.
I'd be surprised if there is a JCK test expecting NPE. Will see.
I suggest to update @param record to say "a LogRecord or null"
to be explicit.
Mandy
Hi Mandy,
On 14/02/19 20:20, Mandy Chung wrote:
Fixing the implementation of Handler::isLoggable to return false
if null to match the specification seems similar risk to changing
the spec. What do you think?
How so? I mean - if no line of code is changed, then surely we can't
break existing
Hi Daniel,
I wonder how a null LogRecord can be passed to Handler::isLoggable
in the code path during logging.
The package summary specifies that NPE will be thrown for null
argument unless it's explicitly specified. Handler.isLoggable
does specify to return false if LogRecord is null. If you
On Wed, Feb 13, 2019 at 6:45 PM Stuart Marks
wrote:
>
> If we all agree on this, I'll proceed with working up a changeset for
> JDK-6394757.[3] It's time to fix this one.
>
Thanks for taking on the fixing of this unfixable problem.
It's important to do lots of documentation/guidance work, esp.
Hi Daniel,
> On Feb 14, 2019, at 2:22 PM, Daniel Fuchs wrote:
>
> Hi Lance,
>
> On 14/02/2019 20:18, Lance Andersen wrote:
>> Documenting the current behavior as it has been makes the most sense to me
>> as well
>> Have you created a CSR yet? if so I will add myself as a reviewer?
>
> I
Hi Lance,
On 14/02/2019 20:18, Lance Andersen wrote:
Documenting the current behavior as it has been makes the most sense to
me as well
Have you created a CSR yet? if so I will add myself as a reviewer?
I haven't created a CSR yet.
This is a small low-priority fix - so it seemed
Hi Daniel
> On Feb 14, 2019, at 2:10 PM, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a doc fix for:
>
> 8216363: NullPointerException in java.util.logging.Handler#isLoggable
> https://bugs.openjdk.java.net/browse/JDK-8216363
>
> webrev:
>
Hi,
Please find below a doc fix for:
8216363: NullPointerException in java.util.logging.Handler#isLoggable
https://bugs.openjdk.java.net/browse/JDK-8216363
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.00/index.html
java.util.logging.Handler specifies that
Right, I see that now.
Care must be exercised if this method is used on collections that
do not comply with the general contract for {@code Collection}.
So, what does this mean? Are we catering to incorrect implementations?
> On Feb 13, 2019, at 9:07 PM, Stuart Marks wrote:
>
> On 2/13/19
Hi Roger,
> Maybe 10 years ago, when native was the only solution.
> Now there are tools to analyze bytecode in java.
I'm working on a Java implementation.
> > Peter Levart proposed to initialize the message with a sentinel instead.
> > I'll implement this as a proposal.
> That's an extra
On 13/02/2019 22:26, Langer, Christoph wrote:
:
Also the "Zip" view of file attributes will need to be fleshed out more
(the view name for example).
I don't know if that's really necessary as the "Zip" view currently is internal
to jdk.zips and I don't propose to export it.
Not exporting it
Hi Mandy,
Apologies for the delay.
Could you review this cdiff as a proposal for the jtreg test?
Made sense to modify the existing test set for MethodHandle rather than
add a new one.
test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java
14 matches
Mail list logo
