Re: Review Request: JDK-8195974: Replace use of java.util.logging

[Nir Lisker]

Tom, is there an Eclipse issue about this in Bugzilla? As I mentioned some
time ago, if I add the dependency to the .classpath it should function the
same as adding it to module-info.

On Tue, May 22, 2018 at 5:37 PM, Tom Schindl 
wrote:

> From a pure library developer point-of-view this would mean JavaFX would
> rely on an implementation detail of the JRE it runs (it's JUnit-Tests).
>
> Does this hold true if I run JavaFX on none Oracle VMs, like Eclipse J9
> - not that i plan but well you know ;-)
>
> Tom
>
> On 22.05.18 14:01, Daniel Fuchs wrote:
> > Hi Nir,
> >
> > By default, the backend of System.Logger is java.util.logging,
> > as long as the java.logging module is present and no
> > custom LoggerFinder service has been deployed.
> >
> > This means that in a usual testing environment, if a library
> > emits a log message using the System.Logger API, then a test
> > for that library should still be able to observe that message
> > using the regular java.util.logging APIs.
> > (unless a LoggerFinder service has explicitly been deployed,
> > or unless the test runs with a --limit-modules option that
> > excludes java.logging).
> >
> > I see that you have changed javafx.base tests to stop using
> > java.util.logging for verifying the log messages produced
> > by javafx.base classes, and I was wondering whether that
> > was really necessary?
> > I mean - this could be necessary if the test was a whitebox
> > test deployed by the test infrastructure in the same module
> > than the code under test, and was therefore limited to only
> > use those modules required by the module-info of that module,
> > but if the test class is deployed on the class path / unnamed
> > module then the test class  should still be able to
> > configure/access java.logging to verify the behaviour
> > of the module under test.
> >
> > best regards,
> >
> > -- daniel
> >
> >
> > On 20/05/2018 13:00, openjfx-dev-requ...@openjdk.java.net wrote:
> >> Hi,
> >>
> >> Please review the fix approach for:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8195974
> >>
> >> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/
> >>
> >> Many details in the issue.
> >>
> >> Thanks,
> >> Nir
> >>
> >
>

Re: Review Request: JDK-8195974: Replace use of java.util.logging

[Tom Schindl]

>From a pure library developer point-of-view this would mean JavaFX would
rely on an implementation detail of the JRE it runs (it's JUnit-Tests).

Does this hold true if I run JavaFX on none Oracle VMs, like Eclipse J9
- not that i plan but well you know ;-)

Tom

On 22.05.18 14:01, Daniel Fuchs wrote:
> Hi Nir,
> 
> By default, the backend of System.Logger is java.util.logging,
> as long as the java.logging module is present and no
> custom LoggerFinder service has been deployed.
> 
> This means that in a usual testing environment, if a library
> emits a log message using the System.Logger API, then a test
> for that library should still be able to observe that message
> using the regular java.util.logging APIs.
> (unless a LoggerFinder service has explicitly been deployed,
> or unless the test runs with a --limit-modules option that
> excludes java.logging).
> 
> I see that you have changed javafx.base tests to stop using
> java.util.logging for verifying the log messages produced
> by javafx.base classes, and I was wondering whether that
> was really necessary?
> I mean - this could be necessary if the test was a whitebox
> test deployed by the test infrastructure in the same module
> than the code under test, and was therefore limited to only
> use those modules required by the module-info of that module,
> but if the test class is deployed on the class path / unnamed
> module then the test class  should still be able to
> configure/access java.logging to verify the behaviour
> of the module under test.
> 
> best regards,
> 
> -- daniel
> 
> 
> On 20/05/2018 13:00, openjfx-dev-requ...@openjdk.java.net wrote:
>> Hi,
>>
>> Please review the fix approach for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8195974
>>
>> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/
>>
>> Many details in the issue.
>>
>> Thanks,
>> Nir
>>
> 

Re: Review Request: JDK-8195974: Replace use of java.util.logging

[Nir Lisker]

Hi Daniel,

I see that you have changed javafx.base tests to stop using
> java.util.logging for verifying the log messages produced
> by javafx.base classes, and I was wondering whether that
> was really necessary?


This was the most acceptable approach. The reason is that using j.u.l.,
even in tests, causes problems for OpenJFX on Eclipse.

This was brought up a few times before: in a discussion about
Eclipse-specific files [1], in the issue comments [2], and in a discussion
about this issue [3].

I waited with the decision to remove j.u.l. completely until all its uses
were understood and I could determine that they are minor enough for a
replacement to be put in at the benefit of being able to develop OpenJFX on
Eclipse. I'm aware that changing code because an IDE doesn't handle it well
it isn't a good practice, but in this case there were no objections. In the
future, if an irreplaceable need to use j.u.l. arises, we can reevaluate
this point and see if Eclipse has made any changes to remove this conflict
(I'm not sure if they're planning to).

The availability of j.u.l. with respect to System.Logger isn't the issue.

[1]
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021743.html

[2]
https://bugs.openjdk.java.net/browse/JDK-8195974?focusedCommentId=14176654=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176654

[3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021893.html

Best,
Nir

On Tue, May 22, 2018 at 3:01 PM, Daniel Fuchs 
wrote:

> Hi Nir,
>
> By default, the backend of System.Logger is java.util.logging,
> as long as the java.logging module is present and no
> custom LoggerFinder service has been deployed.
>
> This means that in a usual testing environment, if a library
> emits a log message using the System.Logger API, then a test
> for that library should still be able to observe that message
> using the regular java.util.logging APIs.
> (unless a LoggerFinder service has explicitly been deployed,
> or unless the test runs with a --limit-modules option that
> excludes java.logging).
>
> I see that you have changed javafx.base tests to stop using
> java.util.logging for verifying the log messages produced
> by javafx.base classes, and I was wondering whether that
> was really necessary?
> I mean - this could be necessary if the test was a whitebox
> test deployed by the test infrastructure in the same module
> than the code under test, and was therefore limited to only
> use those modules required by the module-info of that module,
> but if the test class is deployed on the class path / unnamed
> module then the test class  should still be able to
> configure/access java.logging to verify the behaviour
> of the module under test.
>
> best regards,
>
> -- daniel
>
>
> On 20/05/2018 13:00, openjfx-dev-requ...@openjdk.java.net wrote:
>
>> Hi,
>>
>> Please review the fix approach for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8195974
>>
>> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/
>>
>> Many details in the issue.
>>
>> Thanks,
>> Nir
>>
>>
>

Re: Review Request: JDK-8195974: Replace use of java.util.logging

[Daniel Fuchs]

Hi Nir,

By default, the backend of System.Logger is java.util.logging,
as long as the java.logging module is present and no
custom LoggerFinder service has been deployed.

This means that in a usual testing environment, if a library
emits a log message using the System.Logger API, then a test
for that library should still be able to observe that message
using the regular java.util.logging APIs.
(unless a LoggerFinder service has explicitly been deployed,
or unless the test runs with a --limit-modules option that
excludes java.logging).

I see that you have changed javafx.base tests to stop using
java.util.logging for verifying the log messages produced
by javafx.base classes, and I was wondering whether that
was really necessary?
I mean - this could be necessary if the test was a whitebox
test deployed by the test infrastructure in the same module
than the code under test, and was therefore limited to only
use those modules required by the module-info of that module,
but if the test class is deployed on the class path / unnamed
module then the test class  should still be able to
configure/access java.logging to verify the behaviour
of the module under test.

best regards,

-- daniel


On 20/05/2018 13:00, openjfx-dev-requ...@openjdk.java.net wrote:

Hi,

Please review the fix approach for:

https://bugs.openjdk.java.net/browse/JDK-8195974

http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/

Many details in the issue.

Thanks,
Nir