User component code is likely to put SceneBuilder's process at risk

The ability to enhance the Library content with FX components provided by the users comes with a drawback: the user code has no other choice but being instantiated as we need to known if it is an eligible component in the FX sense.
There's no critics toward user code here, don't misunderstand me ;)
But I bumped an interesting case with the attached jar file: as soon as you add it to your user library directory the CPU used by SceneBuilder jumps up to ~15% (from almost nothing when SB is not used). From there simply let SceneBuilder opened but do not use it: the eaten CPU percentage will continuously increase up to the moment you can't stand it: SB becomes unusable, fan noisy and all the computer is at risk.

Here is what the FX thread is doing:

"JavaFX Application Thread" #12 prio=5 os_prio=31 tid=0x00007f90bd000000 nid=0xd07 runnable [0x00007fff50e2a000]
   java.lang.Thread.State: RUNNABLE
    at eu.hansolo.enzo.roundlcdclock.RoundLcdClock.drawForeground(RoundLcdClock.java:386)
    at eu.hansolo.enzo.roundlcdclock.RoundLcdClock.access$700(RoundLcdClock.java:47)
    at eu.hansolo.enzo.roundlcdclock.RoundLcdClock$1.handle(RoundLcdClock.java:129)
    at javafx.animation.AnimationTimer$AnimationTimerReceiver$1.run(AnimationTimer.java:58)
    at javafx.animation.AnimationTimer$AnimationTimerReceiver$1.run(AnimationTimer.java:56)
    at java.security.AccessController.doPrivileged(Native Method)
    at javafx.animation.AnimationTimer$AnimationTimerReceiver.handle(AnimationTimer.java:56)
    at com.sun.scenario.animation.AbstractMasterTimer.timePulseImpl(AbstractMasterTimer.java:359)
    at com.sun.scenario.animation.AbstractMasterTimer$MainLoop.run(AbstractMasterTimer.java:269)
    at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:475)
    at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:460)
    at com.sun.javafx.tk.quantum.QuantumToolkit$13.run(QuantumToolkit.java:327)
    at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)

We should probably warn the user about the risks; here are rough ideas:

- at start-up and if the user library directory is not empty then we could have a popup window (but doing so all the time is boring, "Do not warn again" check-box is an option), print a message in the Message Bar (sticky or not ?), ...

- at import time the Import dialog could have a text area where a warning message can be read, or when the user clicks the Import button then a warning popup could come out, ...

- each time a JAR analysis is started (which occurs each time the content of the user library directory content changes) then we could print a message in the message bar

Finding the proper level of warning without becoming either frightening or boring, here is the mission !
Thoughts ?