For a user: In Wayland programs are supposed to draw their own title bar. Java aplications and old applications must use a backwards compatibility layer that can cause flicker and bad font rendering. The terminology is different (compositor = window manager). Some niche new programs may only run on Wayland. Wayland hasn’t been adopted by BSD (AFAIK).
For a programners: Wayland has more modern, tidy code, but not all toolkits support it natively and few are easy. If you code exclusively for Wayland, a lot of users won’t use your program at the moment.
In Wayland programs are supposed to draw their own title bar
That’s incorrect. GNOME does it like this, Plasma doesn’t. KDE came up with a standard so a program can communicate this to the DE, GNOME slept on it. That’s why e.g. mpv doesn’t run well on GNOME.
Java aplications and old applications must use a backwards compatibility layer that can cause flicker and bad font rendering.
There have been efforts to provide better support for Java applications on the Wayland. For instance, the OpenJDK project has been making progress on implementing native “pure” Wayland toolkit integration not dependent upon XOrg/X11 or XWayland.
but not all toolkits support it natively and few are easy.
There have been significant developments in providing native support for Wayland in various toolkits. For example : Clutter, GLFW 3, SDL, GTK 3.20+, QT5+, EFL, Slint, Iced & OpenJDK. Just to name a few.
While it is true that not all toolkits have full native support, ongoing work is/has largely shifted towards much better Wayland support.
For a user: In Wayland programs are supposed to draw their own title bar. Java aplications and old applications must use a backwards compatibility layer that can cause flicker and bad font rendering. The terminology is different (compositor = window manager). Some niche new programs may only run on Wayland. Wayland hasn’t been adopted by BSD (AFAIK).
For a programners: Wayland has more modern, tidy code, but not all toolkits support it natively and few are easy. If you code exclusively for Wayland, a lot of users won’t use your program at the moment.
That’s incorrect. GNOME does it like this, Plasma doesn’t. KDE came up with a standard so a program can communicate this to the DE, GNOME slept on it. That’s why e.g. mpv doesn’t run well on GNOME.
There have been efforts to provide better support for Java applications on the Wayland. For instance, the OpenJDK project has been making progress on implementing native “pure” Wayland toolkit integration not dependent upon XOrg/X11 or XWayland.
There have been significant developments in providing native support for Wayland in various toolkits. For example : Clutter, GLFW 3, SDL, GTK 3.20+, QT5+, EFL, Slint, Iced & OpenJDK. Just to name a few.
While it is true that not all toolkits have full native support, ongoing work is/has largely shifted towards much better Wayland support.
OpenJDK has Project Wakefield going on to address Wayland support for Java applications.
https://wiki.openjdk.org/display/wakefield/OpenJDK+Project+Wakefield+-+Wayland+desktop+support+for+JDK+on+Linux