[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: static initialisation of javafx.stage.Screen causing problems with clojure
From:       Peter Levart <peter.levart () gmail ! com>
Date:       2019-03-27 14:08:45
Message-ID: d8f53702-8ffa-66df-c1a6-9b4ae8f6a035 () gmail ! com
[Download RAW message or body]



On 3/26/19 1:18 PM, Răzvan Rotaru wrote:
> Thank you. I don't know whether the clojure compiler needs initialized
> classes or not, but I suspect it does. Clojure has macros, which are
> executed at compile time, which means some classes are instantiated. I will
> ask the clojure developers. If that's the case though it means clojure will
> not be able to compile Java FX. This is actually half bad, since this is
> only needed when one uses something called ahead of time compilation (AOT),
> so one can use Java FX in clojure but not with AOT (i.e. compilation will
> occur at runtime).
>
> But apart from that, I think it's rather strange that class
> loading/initalisation depends on the thread it happens. How do you make
> sure that javafx.stage.Screen is not loaded from the wrong thread?

Java (JVM) loads and initializes classes lazily, when 1st needed. So if 
javafx.stage.Screen API is specified to be invoked in special JavaFX 
Application thread only, then this is where the static initializer will 
get executed too. It seems that this has not been a problem for normal 
(Java-side) use.

Regards, Peter

>
> Regards,
> Răzvan
>
>
> On Mon, 25 Mar 2019 at 17:41, Peter Levart <peter.levart@gmail.com> wrote:
>
>> Hi Razvan,
>>
>> I don't know Clojure but if this happens during compilation of Clojure
>> source(s) (in clojure.lang.Compile), then the question is: Does Clojure
>> compiler really need to execute static initializers of classes it is
>> "resolving"? It seems it needs to load the classes (presumably because
>> it is using Java reflection to introspect them), but does it really need
>> to initialize the classes?
>>
>> If it only needs to introspect the classes (but not execute constructors
>> or methods in them or access fields), then it should be using the 3-arg
>> Class.forName() method:
>>
>>        public static Class<?> forName(String name, boolean initialize,
>> ClassLoader loader)
>>
>> ...passing 'false' as the 2nd argument. That way the "resolved" classes
>> would be loaded but not initialized. Clojure compiler could still
>> introspect them, but no code in classes would be executed. This would be
>> much safer.
>>
>> Regards, Peter
>>
>>
>> On 3/24/19 3:16 PM, Răzvan Rotaru wrote:
>>> Hi,
>>>
>>> I am trying to use OpenJFX 11.0.2 (for Linux) with Clojure and
>>> https://github.com/fn-fx/fn-fx, and stumbled upon a problem for which I
>>> would like to ask for advice here. The Problem occurs during compilation
>> of
>>> some clojure code, which triggers class loading for javafx.stage.Screen,
>>> which fails with following stack trace (only the relevant part):
>>>
>>> java.lang.IllegalStateException: This operation is permitted on the event
>>> thread only; currentThread = main
>>>       at
>> com.sun.glass.ui.Application.checkEventThread(Application.java:441)
>>>       at com.sun.glass.ui.Screen.setEventHandler(Screen.java:369)
>>>       at
>>>
>> com.sun.javafx.tk.quantum.QuantumToolkit.setScreenConfigurationListener(QuantumToolkit.java:684)
>>>       at javafx.stage.Screen.<clinit>(Screen.java:74)
>>>       at java.base/java.lang.Class.forName0(Native Method)
>>>       at java.base/java.lang.Class.forName(Class.java:398)
>>>       at clojure.lang.RT.classForName(RT.java:2207)
>>>       at clojure.lang.RT.classForName(RT.java:2216)
>>>       at clojure.lang.Compiler.resolveIn(Compiler.java:7394)
>>>       at clojure.lang.Compiler.resolve(Compiler.java:7357)
>>>       at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7318)
>>>       at clojure.lang.Compiler.analyze(Compiler.java:6768)
>>>       at clojure.lang.Compiler.analyze(Compiler.java:6745)
>>>       at clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3888)
>>>
>>> Being only compilation, there should be no Toolkit initialisation, hence
>> no
>>> event thread. Looking at the code it seems that the Screen class can only
>>> be loaded from the event thread. Is this a bug or the intended behaviour?
>>> Is there a way around this for my use case? How does OpenJFX ensure that
>>> Screen is always loaded on the correct thread?
>>>
>>> Related bug in fn-fx: https://github.com/fn-fx/fn-fx/issues/25
>>>
>>>
>>> Cheers,
>>> Răzvan
>>>
>>

[prev in list] [next in list] [prev in thread] [next in thread]