Hm, this does seem like something that could happen, although I've never seen that exception at that specific place before either.SVGIcon does contain PropertyChangeSupport instance that strictly may not be cloneable if Unsafe is not useable on your Java version.
You can actually see from this part of the trace:
com.alee.utils.reflection.Unsafe.allocateInstanceThroughReflection(Unsafe.java:127)
com.alee.utils.reflection.Unsafe.allocateInstance(Unsafe.java:62)That WebLaF's Unsafe tried to allocate object instance via sun.misc.Unsafe and failed.
As a result it attempted to create instance via empty constructor and also failed resulting in the error.
There is a third option of instance allocation, but it only applies to Serializable objects and PropertyChangeSupport is serializable, so it's weird why it didn't go further. Or it did and failed at that attempt as well, it's hard to say since the stack trace code lines seem to mismatch the class sources.
WebLaF's Unsafe for reference -
https://github.com/mgarin/weblaf/blob/c5d6b3931879a4da2fdebf7ee01868f1969d75f4/modules/core/src/com/alee/utils/reflection/Unsafe.java#L56
It is somewhat unusual for all three ways of instance allocation to fail though.
@geniot
Currently majority of L&F boot time is reading & compiling of XML styles into runtime objects that are then used by component UIs.
The only way to reduce boot time with current implementation, unfortunately, is to reduce amount of styles that are loaded.
It is possible to do via creating a fully custom skin with only the styles you need, but that is a tedious and quite lengthy task.
That being said, since the last year I've been working on an improving the approach to load & compile styles to reduce boot time dramatically.
To put it simple - styles will be compiled lazily on demand instead of having all of them compiled at initialization.
I still haven't finished all of the changes unfortunately, but they will be included in v1.3.0 once it goes live.
You can read more about it here: #595
I had that update planned to go live last year, but unfortunately I didn't have enough time to finish working on it up until now.
I absolutely do plan to get back to it as soon as possible, but I can't really give any specific ETA on it.
I am also planning to finish some smaller bugfixes and improvements in v1.2.14 and release it soon, but boot time improvements will take more time to complete as that part is crucial and have to work perfectly under all circumstances (with all style variations and existing styling system features).
I tried that approach at some point, but compiled styles are much heavier and you'll be trading overhead of reading a few of them from the drive and compiling them for overhead of reading a lot of them from the drive. Whether compiled styles are in XML or in some binary format didn't seem to matter much, read time would take all the time that is taken by the compiling right now. It might seem like a good idea at first, but in reality - it will result in approximately the same boot time, it will of course vary depending on how fast your drive is and how fast your CPU is. Current approach is mostly CPU-heavy (works much faster on higher-clocked CPUs), precompiled approach would be both drive-heavy and CPU-heavy due to the sheer amount of styles to be loaded (1000~1500).
As for Reflection - it is used a lot to create UIs and Painters and to update their settings which happens whenever components are created and not at the L&F boot, so Reflection isn't just used during the boot time but also in runtime. But that doesn't matter too much anyway because Reflection is pretty fast in newer JVM versions plus I have a lot of cache in place that makes methods & fields lookup quick and easy, so it doesn't actually affect performance as much as you might think it does.
In general I agree that Reflection should be used as little as possible or not used at all, but the reality is - it would take exponentially more time to write and support an agile styling system for all existing component variations without using it. Another issue is - some Reflection calls are also necessary to access proprietary Swing APIs to enable/fix various things - for instance to properly utilize system fonts or to acess some Window features that weren't public in earlier Java versions. Some of those issues will go away once WebLaF stops supporting Java 6 and switches to higher lowest supported version, but for now it's just not possible to get around without Reflection usage.
@Abu-Abdullah
Most icons in components that I have moved to new styling system are defined in icon sets, so it should be possible to simply replace them.
You can find two existing icon sets here:
https://github.com/mgarin/weblaf/tree/master/modules/ui/src/com/alee/iconset
Their definition, similarly to skins, can be found in according XML files, for example light one:
https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/iconset/resources/light-icon-set.xml
To replace any icon from existing icon set you simply need to register new icon set with the icon that has the same identifier as the one you want to replace.
Both old and new sets will be preserved, but sets that are registered last will have priority when icons are retrieved.
This is sort of a temporary solution while there is no better way to replace/override icons from existing sets, but it should suffice.
In your case you might need to replace all icons from the core icon set and simply provide new size, for example:
<!-- General purpose icons -->
<SvgIcon id="underline" path="underline.svg" size="24,24">
<SvgFill selector="svg" color="80,80,80" />
</SvgIcon>It should work fine since all icons are SVG-based and can be rescaled without any issues in runtime.
Once you have created your custom icon set XML definition with all icons reconfigured to 24x24 size you will need to provide that icon set into IconManager.
To do that you will first need to create a small class extending XmlIconSet, like the core LightIconSet, for example:
public final class MyIconSet extends XmlIconSet
{
public MyIconSet ()
{
super ( new ClassResource ( MyIconSet.class, "resources/my-icon-set.xml" ) );
}
}Then you simply need to add it into IconManager from the code:
IconManager.addIconSet ( myIconSet );Or by specifying it in your custom skin or skin extension (if you have one):
<iconSet>com.test.MyIconSet</iconSet>Both options are valid, but second one might be more convenient if you already have a custom skin or skin extension.
You can also check wiki article about IconManager usage:
https://github.com/mgarin/weblaf/wiki/How-to-use-IconManager
The main issue with that approach - and why I called it a "temporary solution" - is keeping your custom icon set up-to-date.
There won't be any issues if you miss some icons, but those will be rendered with their default settings from core set.
Ultimately there might be some better ways to implement icons scaling/recoloring without having to overwrite the whole set.
Maybe similar to variables solution that will be introduced for skins and styles, but I haven't really looked into that yet.
@kovadam69
My original plan was to rework file chooser once project is moved to Java 8+ (or even later one) to incorporate all the NIO improvements, but this might indeed take a long while to get to. And keeping one of the more imprortant and often used components in a bad state is definitely not a good thing. So the best course would be to simply rework it at the current project stage and then improve it a bit further after the minimum supported Java version is increased.
So I've compiled a list of issues related to file chooser in one place: #677
And I'm planning to adress most of them in v1.2.15 update.
This will be a complete revamp of file chooser (and possibly WebFileTree component) so some of the features and APIs might change as a result, especially for WebFileChooserPanel as the core component of the file chooser.
Is there a chance to have it in the near future?
Even though I'm planning it for only one update up the line, it might still take some time. As you've noticed - this year been pretty "dry" on updates, mostly because I've been buried under other projects and due to some other reasons. Work on v1.3.0 is still ongoing and is pretty massive in scale, plus some problems staggered v1.2.14 release as well.
That being said, I've been getting more time to work on WebLaF recently, so there is a good chance that v1.2.14 will be out pretty soon and that I'll start working on v1.2.15 (which might potentially only include file chooser changes). Can't really promise any specific date, but according to current projects - v.1.2.14 should be available early November and v1.2.15 might be available somewhere in early December.
What could I do, if NIO filechooser is not on the radar yet?
As @Sciss mentioned - you can use a different UI implementation, although that might be pretty inconvenient on practice.
I don't really see any other easy/quick solutions to the problem unfortunately. Part of the reason why it was always delayed in the first place is the difficulty of making a proper implementation. Although the issues with the current implementation are definitely on me there, it's one of the oldest chunks of code in WebLaF that I wish would've been written better.
I may have heard about an issue like this once, but it's been quite a while (couple of years) ago so I don't recall the details.
I couldn't really find any related bugs in JDK bugtracker and no mentions of something like that.
I will ask my colleague on Monday if he ever encountered it since he works more on Linux and encountered lots of various UI issues in Swing apps.
A few questions about the issue specifically:
- Is mouse input still working on the app after keyboard input stops working?
- Does the application window native decoration look like it still has focus?
- Does this happen with WebLaF only? or any Swing app? is there any chance to isolate a small example app?
And some general questions:
- What is you specific Linux version and desktop environment?
- Which exact Open JDK build are you using?
A few possible things you can try:
- Check some variables of the
Windowinstance of the app in debug once the issue appears, specifically - whether it is focusable and what's the window type is - You can try adding (if mouse inputs are active) a button to your app that will allow you to reset focusable window state in runtime and check if that restores keyboard functioning once the bug appears
@Sciss I tried looking for some more clues or mentions about the problem you described and unfortunately haven't seen anything exactly like what you mentioned. My colleague also said he haven't encountered such problem, only some general issues with UI hanging up on Linux which is unrelated.
Overall the problem you've described sounds like a nasty mix of some specific desktop environment version, Java version and maybe even some specifics of your application UI & code. If that's the case - it might be extremely hard to track down and reproduce if either of conditions isn't met.
The only way to solve such issue is to start eliminating variables one by one
Yes, exactly. I will start by moving to a new computer with new OS (Debian 11) this weekend, so there's that ;) If it persists, I will integrate some debug printing function so I can see the last keyboard events, for example, that were received before the problem. If I find anything that relates to WebLaF I will let you know.