Support to JAVA 17

[dagos83]

When is planned to add support on JAVA 17?
We have some problems with Windows and JAVA 17 on these classes:
WindowsTableHeaderUI and its extensions.

Code: Select all

Caused by: java.lang.IllegalAccessError: superclass access check failed: class com.jidesoft.plaf.windows.WindowsCellStyleTableHeaderUI (in unnamed module @0x1ab3a8c8) cannot access class
com.sun.java.swing.plaf.windows.WindowsTableHeaderUI (in module java.desktop) because module java.desktop does not export com.sun.java.swing.plaf.windows to unnamed module @0x1ab3a8c8
    at java.base/java.lang.ClassLoader.defineClass1(Native Method)
    at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
    at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
    at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
    at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
    at java.base/java.lang.ClassLoader.defineClass1(Native Method)
    at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
    at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
    at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
    at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:375)
    at com.jidesoft.grid.CellStyleTableHeader.updateUI(Unknown Source)
    at java.desktop/javax.swing.table.JTableHeader.<init>(JTableHeader.java:190)
    at com.jidesoft.grid.DraggingTableHeader.<init>(Unknown Source)
    at com.jidesoft.grid.CellStyleTableHeader.<init>(Unknown Source)
    at com.jidesoft.grid.SortableTableHeader.<init>(Unknown Source)
    at com.jidesoft.grid.SortableTable.createDefaultTableHeader(Unknown Source)
    at java.desktop/javax.swing.JTable.initializeLocalVars(JTable.java:5613)
    at java.desktop/javax.swing.JTable.<init>(JTable.java:706)
    at java.desktop/javax.swing.JTable.<init>(JTable.java:632)
    at com.jidesoft.grid.JideTable.<init>(Unknown Source)
    at com.jidesoft.grid.ContextSensitiveTable.<init>(Unknown Source)
    at com.jidesoft.grid.NavigableTable.<init>(Unknown Source)
    at com.jidesoft.grid.CellStyleTable.<init>(Unknown Source)
    at com.jidesoft.grid.CellSpanTable.<init>(Unknown Source)
    at com.jidesoft.grid.CategorizedTable.<init>(Unknown Source)
    at com.jidesoft.grid.SortableTable.<init>(Unknown Source)

Is it possible to have a timeline for the full support of Java 17?
Thanks in advance,
Daniel

[JIDE Support]

We can create a separate version that runs on Java 17 but it will lose a significant amount of features. We are not sure if worth doing it.

[dagos83]

Thank you for your answer.
Can we have a list of the features that will be lost?
Daniel

[JIDE Support]

Pretty much anything related to Windows native intergration or Sync L&F integration. For example, ExComboBox that looks like Windows native ComboBox. RangeSlider that looks like Windows native slider. We will do some estimate. The whole problem here is now we will have to have two code branches to maintain which is really pain.

[dagos83]

Thank you for your reply, we understand your pain.
For what we saw the involved UI are these:
- CellStyleTableHeaderUI
- SortableTableHeaderUI
- NestedTableHeaderUI
- EditableTableHeaderUI
- AutoFilterTableHeaderUI
- GroupTableHeaderUI
- ExComboBoxUI
Am I right?
Probably, since we use another L&F, is not a problem for us to lose windows functionality.
When is it possible to have the new version?

[gtt]

Concerning Look&Feel Investigantions

please have a deeper look at: https://github.com/JFormDesigner/FlatLaf

This is a really amazing thing and opportunity to get closer to WebUI Designs.

[scardenasg]

Hello, we have some customers requesting that our software supports Java17 and one of the components in our software is Jide, so we are also very interested in Jide support for Java17.
Is there any news about the timeline for Jide support for Java17?

[JIDE Support]

Hi scardenasg,

Here is what I replied earlier.

Pretty much anything related to Windows native integration or Sync L&F integration. For example, ExComboBox looks like Windows native ComboBox. RangeSlider looks like Windows native slider. We will do some estimates. The whole problem here is now we will have to have two code branches to maintain which is really painful.

[mregalbuto]

My company uses JIDE components in a Java desktop application. I am in the process of migrating this application to build and run under Java 17. Because I have no other choice, I have adopted the "--add-opens" approach to accessing the private code that is normally not available in Java 17. It is working, but is not, as far as I am concerned, an ideal solution. It is simply "kicking the can down the road". At some point, it will stop working, and our customers will not be able to upgrade to newer Java versions.

For what it's worth, our application uses a platform-independent look and feel, so losing Windows native L&F elements is not important to us.

I realize that it will be difficult to produce a Java 17-compatible version of the JIDE code. However, if we cannot get one, we will have to rewrite our user interface to use some other vendor's components that ARE compatible with newer Java versions. That is a lose-lose situation for both my company and JIDESoft.

[kobi_sadoun]

Is there any plan for upgrading JIDE products for JDK17 (without adding --add-opens)?

[nad]

Does anyone have a comprehensive list of the --add-opens modules/packages for Jide to work on JDK 17?

I don't require the Windows native L&F.

Thank you

[kobi_sadoun]

This works for me:

--add-exports=java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED
--add-exports=java.desktop/javax.swing.plaf.synth=ALL-UNNAMED
--add-exports=java.desktop/sun.awt.shell=ALL-UNNAMED
--add-exports=java.desktop/sun.swing=ALL-UNNAMED
--add-exports=java.desktop/sun.awt=ALL-UNNAMED
--add-exports=java.desktop/sun.awt.windows=ALL-UNNAMED
--add-exports=java.desktop/sun.awt.image=ALL-UNNAMED
--add-exports=java.base/sun.security.action=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED
--add-opens=java.desktop/java.awt=ALL-UNNAMED

[gtt]

This works for us, at the moment....
This list will be continiously expanded as needed...

--add-exports java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED
--add-exports java.desktop/sun.swing=ALL-UNNAMED
--add-exports java.base/sun.security.action=ALL-UNNAMED
--add-exports java.desktop/sun.awt.windows=ALL-UNNAMED
--add-exports java.desktop/sun.awt.image=ALL-UNNAMED
--add-exports java.desktop/sun.awt.shell=ALL-UNNAMED
--add-opens java.desktop/java.awt=ALL-UNNAMED
--add-opens java.desktop/java.awt.color=ALL-UNNAMED
--add-opens java.desktop/javax.swing=ALL-UNNAMED
--add-opens java.base/java.lang=ALL-UNNAMED
--add-opens java.base/java.util=ALL-UNNAMED
--add-opens java.base/java.text=ALL-UNNAMED
--add-opens java.base/java.math=ALL-UNNAMED
--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
--add-opens java.xml/com.sun.org.apache.xml.internal.serialize=ALL-UNNAMED

[oldrookey]

This is not a big problem for my use case. I am building a desktop app and I just add a few more lines to the jar manifest, that way the add-exports do not need to be specified on the command line. For example:

Manifest-Version: 1.0
Main-Class: org.example.MyMainClass
Add-Exports: java.desktop/com.sun.java.swing.plaf.windows