New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java 9/JDK9 compatibility #2594

Open
Siedlerchr opened this Issue Feb 28, 2017 · 25 comments

Comments

Projects
None yet
7 participants
@Siedlerchr
Contributor

Siedlerchr commented Feb 28, 2017

JabRef does not run on Java9

This issue collects all java 9 related problems. Starting point: http://discourse.jabref.org/t/cannot-start-jabref-3-7-3-6-using-java-9-on-ubuntu-16-04/361/8

Not supported JREs

This presents some JRE outputs to support issue finding during search.

Keywords: Java9, Java 9, JRE9, JRE 9

openjdk version "9.0.1"
OpenJDK Runtime Environment (build 9.0.1+11-Debian-1)
OpenJDK 64-Bit Server VM (build 9.0.1+11-Debian-1, mixed mode)

Development hints

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Mar 1, 2017

Contributor

Apple/OSX compatibility:

These new methods replace the functionality of the internal APIs contained in the OS X package com.apple.eawt which are not accessible by default in JDK 9. Note that the package com.apple.eio is no longer accessible and no public replacement exists in JDK 9.

http://openjdk.java.net/jeps/272
http://download.java.net/java/jdk9/docs/api/java/awt/Desktop.html#setOpenFileHandler-java.awt.desktop.OpenFilesHandler-

Please note that for Mac OS, notifications are only sent if the Java app is a bundled application, with a CFBundleDocumentTypes array present in its Info.plist. See the Info.plist Key Reference for more information about adding a CFBundleDocumentTypes key to your app's Info.plist.
Contributor

Siedlerchr commented Mar 1, 2017

Apple/OSX compatibility:

These new methods replace the functionality of the internal APIs contained in the OS X package com.apple.eawt which are not accessible by default in JDK 9. Note that the package com.apple.eio is no longer accessible and no public replacement exists in JDK 9.

http://openjdk.java.net/jeps/272
http://download.java.net/java/jdk9/docs/api/java/awt/Desktop.html#setOpenFileHandler-java.awt.desktop.OpenFilesHandler-

Please note that for Mac OS, notifications are only sent if the Java app is a bundled application, with a CFBundleDocumentTypes array present in its Info.plist. See the Info.plist Key Reference for more information about adding a CFBundleDocumentTypes key to your app's Info.plist.
@kaimast

This comment has been minimized.

Show comment
Hide comment
@kaimast

kaimast Apr 17, 2017

I get the following error when trying to run JabRef on Linux with OpenJDK9. Should I file a new ticket for this?

kai@chipad:~/Downloads$ java -jar ./JabRef-3.8.2.jar
Apr 17, 2017 10:42:01 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
10:42:02.130 [AWT-EventQueue-0] INFO  net.sf.jabref.migrations.PreferencesMigrations - Migrating old custom entry types.
10:42:02.389 [AWT-EventQueue-0] ERROR net.sf.jabref.FallbackExceptionHandler - Uncaught exception Occurred in Thread[AWT-EventQueue-0,6,main]
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
	at net.sf.jabref.logic.importer.ImportFormatReader.resetImportFormats(ImportFormatReader.java:56) ~[JabRef-3.8.2.jar:?]
	at net.sf.jabref.JabRefMain.start(JabRefMain.java:78) ~[JabRef-3.8.2.jar:?]
	at net.sf.jabref.JabRefMain.lambda$main$0(JabRefMain.java:40) ~[JabRef-3.8.2.jar:?]
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) ~[?:?]
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:759) ~[?:?]
	at java.awt.EventQueue.access$500(EventQueue.java:97) ~[?:?]
	at java.awt.EventQueue$3.run(EventQueue.java:712) ~[?:?]
	at java.awt.EventQueue$3.run(EventQueue.java:706) ~[?:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:88) ~[?:?]
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:729) ~[?:?]
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) [?:?]
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) [?:?]
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) [?:?]
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) [?:?]
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) [?:?]
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) [?:?]
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
	at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533) ~[?:?]
	at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186) ~[?:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:476) ~[?:?]
	... 17 more

kaimast commented Apr 17, 2017

I get the following error when trying to run JabRef on Linux with OpenJDK9. Should I file a new ticket for this?

kai@chipad:~/Downloads$ java -jar ./JabRef-3.8.2.jar
Apr 17, 2017 10:42:01 AM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
10:42:02.130 [AWT-EventQueue-0] INFO  net.sf.jabref.migrations.PreferencesMigrations - Migrating old custom entry types.
10:42:02.389 [AWT-EventQueue-0] ERROR net.sf.jabref.FallbackExceptionHandler - Uncaught exception Occurred in Thread[AWT-EventQueue-0,6,main]
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
	at net.sf.jabref.logic.importer.ImportFormatReader.resetImportFormats(ImportFormatReader.java:56) ~[JabRef-3.8.2.jar:?]
	at net.sf.jabref.JabRefMain.start(JabRefMain.java:78) ~[JabRef-3.8.2.jar:?]
	at net.sf.jabref.JabRefMain.lambda$main$0(JabRefMain.java:40) ~[JabRef-3.8.2.jar:?]
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) ~[?:?]
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:759) ~[?:?]
	at java.awt.EventQueue.access$500(EventQueue.java:97) ~[?:?]
	at java.awt.EventQueue$3.run(EventQueue.java:712) ~[?:?]
	at java.awt.EventQueue$3.run(EventQueue.java:706) ~[?:?]
	at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:88) ~[?:?]
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:729) ~[?:?]
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199) [?:?]
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) [?:?]
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) [?:?]
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) [?:?]
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) [?:?]
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) [?:?]
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
	at jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533) ~[?:?]
	at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186) ~[?:?]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:476) ~[?:?]
	... 17 more
@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Apr 17, 2017

Contributor

Thanks for your report. this is a problem we still have to solve.
A while ago I posted a workaround: You need to clone the repo and compile the code (with jdk8) for yourself using ./gradlew build (ignore the failing tests). That will generate some startup scripts that work with jdk9

Contributor

Siedlerchr commented Apr 17, 2017

Thanks for your report. this is a problem we still have to solve.
A while ago I posted a workaround: You need to clone the repo and compile the code (with jdk8) for yourself using ./gradlew build (ignore the failing tests). That will generate some startup scripts that work with jdk9

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Aug 17, 2017

Contributor

As jdk9 is on it's way to the final release, we definitely should focus on getting JabRef to work with jdk9.

Contributor

Siedlerchr commented Aug 17, 2017

As jdk9 is on it's way to the final release, we definitely should focus on getting JabRef to work with jdk9.

@koppor koppor referenced this issue Aug 18, 2017

Merged

Pin Java to 8 #8

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Sep 23, 2017

Contributor

Okay, the final release of java 9 is out and I played around with jdeps to anaylze dependencies to internal jdk libs:
To summarize:
controlsfx
Our custom hack
and wiremock

build -> JDK removed internal API
build -> javafx.controls
build -> javafx.graphics
   org.jabref.gui.customjfx.CustomJFXPanel            -> com.sun.javafx.embed.EmbeddedSceneInterface        JDK internal API (javafx.graphics)
   org.jabref.gui.fieldeditors.EditorTextArea         -> com.sun.javafx.scene.control.behavior.BehaviorBase JDK internal API (javafx.controls)
   org.jabref.gui.fieldeditors.EditorTextArea         -> com.sun.javafx.scene.control.behavior.TextAreaBehavior JDK internal API (javafx.controls)
   org.jabref.gui.fieldeditors.EditorTextArea         -> com.sun.javafx.scene.control.skin.TextAreaSkin     JDK internal API (JDK removed internal API)
   org.jabref.gui.fieldeditors.EditorTextArea$1       -> com.sun.javafx.scene.control.skin.TextAreaSkin     JDK internal API (JDK removed internal API)
   org.jabref.logic.l10n.LocalizationParser           -> com.sun.javafx.application.PlatformImpl            JDK internal API (javafx.graphics)
customjfx-1.0.0.jar -> javafx.base
customjfx-1.0.0.jar -> javafx.graphics
   org.jabref.gui.customjfx.support.InputMethodSupport -> com.sun.javafx.collections.ObservableListWrapper   JDK internal API (javafx.base)
   org.jabref.gui.customjfx.support.InputMethodSupport$InputMethodRequestsAdapter -> com.sun.javafx.scene.input.ExtendedInputMethodRequests JDK internal API (javafx.graphics)
objenesis-2.6.jar -> jdk.unsupported
   org.objenesis.instantiator.sun.UnsafeFactoryInstantiator -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.objenesis.instantiator.util.ClassDefinitionUtils -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.objenesis.instantiator.util.UnsafeUtils        -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
wiremock-2.8.0.jar -> java.xml
   com.github.tomakehurst.wiremock.matching.EqualToXmlPattern$SkipResolvingEntitiesDocumentBuilderFactory -> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl JDK internal API (java.xml)


Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependence on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.misc.Unsafe                          See http://openjdk.java.net/jeps/260

Contributor

Siedlerchr commented Sep 23, 2017

Okay, the final release of java 9 is out and I played around with jdeps to anaylze dependencies to internal jdk libs:
To summarize:
controlsfx
Our custom hack
and wiremock

build -> JDK removed internal API
build -> javafx.controls
build -> javafx.graphics
   org.jabref.gui.customjfx.CustomJFXPanel            -> com.sun.javafx.embed.EmbeddedSceneInterface        JDK internal API (javafx.graphics)
   org.jabref.gui.fieldeditors.EditorTextArea         -> com.sun.javafx.scene.control.behavior.BehaviorBase JDK internal API (javafx.controls)
   org.jabref.gui.fieldeditors.EditorTextArea         -> com.sun.javafx.scene.control.behavior.TextAreaBehavior JDK internal API (javafx.controls)
   org.jabref.gui.fieldeditors.EditorTextArea         -> com.sun.javafx.scene.control.skin.TextAreaSkin     JDK internal API (JDK removed internal API)
   org.jabref.gui.fieldeditors.EditorTextArea$1       -> com.sun.javafx.scene.control.skin.TextAreaSkin     JDK internal API (JDK removed internal API)
   org.jabref.logic.l10n.LocalizationParser           -> com.sun.javafx.application.PlatformImpl            JDK internal API (javafx.graphics)
customjfx-1.0.0.jar -> javafx.base
customjfx-1.0.0.jar -> javafx.graphics
   org.jabref.gui.customjfx.support.InputMethodSupport -> com.sun.javafx.collections.ObservableListWrapper   JDK internal API (javafx.base)
   org.jabref.gui.customjfx.support.InputMethodSupport$InputMethodRequestsAdapter -> com.sun.javafx.scene.input.ExtendedInputMethodRequests JDK internal API (javafx.graphics)
objenesis-2.6.jar -> jdk.unsupported
   org.objenesis.instantiator.sun.UnsafeFactoryInstantiator -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.objenesis.instantiator.util.ClassDefinitionUtils -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.objenesis.instantiator.util.UnsafeUtils        -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
wiremock-2.8.0.jar -> java.xml
   com.github.tomakehurst.wiremock.matching.EqualToXmlPattern$SkipResolvingEntitiesDocumentBuilderFactory -> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl JDK internal API (java.xml)


Warning: JDK internal APIs are unsupported and private to JDK implementation that are
subject to be removed or changed incompatibly and could break your application.
Please modify your code to eliminate dependence on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.misc.Unsafe                          See http://openjdk.java.net/jeps/260

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Sep 26, 2017

Contributor

Controlsfx has a java9 comptaible 9.0.0 release http://fxexperience.com/controlsfx/
FontawesomeFX is working on java 9 support: https://bitbucket.org/Jerady/fontawesomefx/issues/48/cssparser-unavailable-in-java-9

Contributor

Siedlerchr commented Sep 26, 2017

Controlsfx has a java9 comptaible 9.0.0 release http://fxexperience.com/controlsfx/
FontawesomeFX is working on java 9 support: https://bitbucket.org/Jerady/fontawesomefx/issues/48/cssparser-unavailable-in-java-9

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Sep 27, 2017

Contributor

FontawesomeFX 9.0.0 is out, with java 9 module support
http://www.jensd.de/wordpress/?p=2686

Contributor

Siedlerchr commented Sep 27, 2017

FontawesomeFX 9.0.0 is out, with java 9 module support
http://www.jensd.de/wordpress/?p=2686

@tobiasdiez

This comment has been minimized.

Show comment
Hide comment
@tobiasdiez

tobiasdiez Sep 27, 2017

Member

wiremock shouldn't be a problem as it is only used in the tests

Member

tobiasdiez commented Sep 27, 2017

wiremock shouldn't be a problem as it is only used in the tests

@lenhard

This comment has been minimized.

Show comment
Hide comment
@lenhard

lenhard Oct 3, 2017

Member

So just to sum up and make sure that I understand everything: Our major problems with Java 9 are:

  • Some apple extensions are gone and we are going to need special packaging for IOS?
  • We need a release of OpenJDK with a fix to the special characters bug (did they honestly push the fix that they already implemented to v10 as in Java 10? Please tell me this is not true) or we need to change our local fix for it (this smells very much like a blocker).
Member

lenhard commented Oct 3, 2017

So just to sum up and make sure that I understand everything: Our major problems with Java 9 are:

  • Some apple extensions are gone and we are going to need special packaging for IOS?
  • We need a release of OpenJDK with a fix to the special characters bug (did they honestly push the fix that they already implemented to v10 as in Java 10? Please tell me this is not true) or we need to change our local fix for it (this smells very much like a blocker).
@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Oct 3, 2017

Contributor

The main blocker is that we have to adjust our start build scripts/installer to add these command line parameter for module config stuff.
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6

Apple Extensions have somehow been directly incorporated (If I read the changelog correct)

Contributor

Siedlerchr commented Oct 3, 2017

The main blocker is that we have to adjust our start build scripts/installer to add these command line parameter for module config stuff.
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6

Apple Extensions have somehow been directly incorporated (If I read the changelog correct)

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr
Contributor

Siedlerchr commented Oct 17, 2017

@koppor

This comment has been minimized.

Show comment
Hide comment
@koppor

koppor Nov 10, 2017

Member

@lenhard Since OracleJDK is a somehow a commerical product, there won't be any backport. We can either skip Java9 or change our local fix. @Siedlerchr or @lenhard Can you create an issue at https://github.com/JabRef/org.jabref.gui.customjfx.support/issues so that we can track that?

Member

koppor commented Nov 10, 2017

@lenhard Since OracleJDK is a somehow a commerical product, there won't be any backport. We can either skip Java9 or change our local fix. @Siedlerchr or @lenhard Can you create an issue at https://github.com/JabRef/org.jabref.gui.customjfx.support/issues so that we can track that?

@koppor koppor referenced this issue Nov 10, 2017

Closed

[WIP] Java9 support #3425

1 of 6 tasks complete
@koppor

This comment has been minimized.

Show comment
Hide comment
@koppor

koppor Nov 10, 2017

Member

I began a skeletton for working on the Java9 support at #3425

Feel free to continue. I personally could have time in December or January for that, but not earlier.

Member

koppor commented Nov 10, 2017

I began a skeletton for working on the Java9 support at #3425

Feel free to continue. I personally could have time in December or January for that, but not earlier.

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Nov 10, 2017

Contributor

@koppor The fix was in the OpenJDK - There we did get the fixed code
https://bugs.openjdk.java.net/browse/JDK-8185792

Contributor

Siedlerchr commented Nov 10, 2017

@koppor The fix was in the OpenJDK - There we did get the fixed code
https://bugs.openjdk.java.net/browse/JDK-8185792

@lenhard lenhard referenced this issue Nov 24, 2017

Merged

Replace swingx with standard swing #3454

1 of 6 tasks complete
@lenhard

This comment has been minimized.

Show comment
Hide comment
@lenhard

lenhard Nov 24, 2017

Member

I think that jgoodies is going to become a major problem. The versions we use seem to use internal APIs (correct me if I'm wrong) and the newer versions of jgoodies are no longer free.

Hence, we will need to replace the usage of jgoodies, but it is used in so many places. The default look and feels are even based on it.

Member

lenhard commented Nov 24, 2017

I think that jgoodies is going to become a major problem. The versions we use seem to use internal APIs (correct me if I'm wrong) and the newer versions of jgoodies are no longer free.

Hence, we will need to replace the usage of jgoodies, but it is used in so many places. The default look and feels are even based on it.

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Nov 24, 2017

Contributor

Time to migrate all to javafx. For java 9 there are compatibility switches to allow internal API access. To see what deps use internal apis you can run the jdeps cli Tool fRom the jdk9

Contributor

Siedlerchr commented Nov 24, 2017

Time to migrate all to javafx. For java 9 there are compatibility switches to allow internal API access. To see what deps use internal apis you can run the jdeps cli Tool fRom the jdk9

@lenhard

This comment has been minimized.

Show comment
Hide comment
@lenhard

lenhard Nov 24, 2017

Member

I have inspected the libraries we use. jgoodies-common and jgoodies-forms seem to be fine (haven't seen JDK internal API there), but for for jgoodies-looks, there's this dependency:

on jgoodies-looks-2.7.0.jar   com.jgoodies.looks.windows  -> com.sun.java.swing.plaf.windows  JDK internal API (java.desktop)

If I interpret everything right that means that we don't have too much pressure from jgoodies for layouting (good), but we'll have to find a solution for the look and feels. That might be small code changes, but with a wider effect.

Member

lenhard commented Nov 24, 2017

I have inspected the libraries we use. jgoodies-common and jgoodies-forms seem to be fine (haven't seen JDK internal API there), but for for jgoodies-looks, there's this dependency:

on jgoodies-looks-2.7.0.jar   com.jgoodies.looks.windows  -> com.sun.java.swing.plaf.windows  JDK internal API (java.desktop)

If I interpret everything right that means that we don't have too much pressure from jgoodies for layouting (good), but we'll have to find a solution for the look and feels. That might be small code changes, but with a wider effect.

@lenhard lenhard referenced this issue Nov 25, 2017

Merged

Remove dependency to jgoodies-looks #3458

2 of 6 tasks complete
@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Nov 27, 2017

Contributor

A nice guide for legacy conversion to java 9
https://techbeacon.com/legacy-developers-guide-java-9

Contributor

Siedlerchr commented Nov 27, 2017

A nice guide for legacy conversion to java 9
https://techbeacon.com/legacy-developers-guide-java-9

@koppor

This comment has been minimized.

Show comment
Hide comment
@koppor

koppor Nov 27, 2017

Member

@lenhard If that is the only dependency, maybe we can patch jgoodies-looks to use UIManager.getSystemLookAndFeelClassName() instead? (See https://docs.oracle.com/javase/8/docs/technotes/guides/swing/1.4/Post1.4.html). Maybe, we can even go without patching if we avoid the respective method in JGoodies looks to be used at all? ^^

Member

koppor commented Nov 27, 2017

@lenhard If that is the only dependency, maybe we can patch jgoodies-looks to use UIManager.getSystemLookAndFeelClassName() instead? (See https://docs.oracle.com/javase/8/docs/technotes/guides/swing/1.4/Post1.4.html). Maybe, we can even go without patching if we avoid the respective method in JGoodies looks to be used at all? ^^

@lenhard

This comment has been minimized.

Show comment
Hide comment
@lenhard

lenhard Nov 28, 2017

Member

@koppor We might be able to do that. But instead of endlessly sticking to arcane technology (jgoodies has left open source almost three years ago), I am for cutting it and moving forward. Maybe we should be looking for newer look and feels instead?

We can discuss this of course.

Member

lenhard commented Nov 28, 2017

@koppor We might be able to do that. But instead of endlessly sticking to arcane technology (jgoodies has left open source almost three years ago), I am for cutting it and moving forward. Maybe we should be looking for newer look and feels instead?

We can discuss this of course.

@koppor

This comment has been minimized.

Show comment
Hide comment
@koppor

koppor Jan 25, 2018

Member

Migration to Java9 should also offer easy extraction/separation of libraries such as org.jabref.model. Refs #110.

Member

koppor commented Jan 25, 2018

Migration to Java9 should also offer easy extraction/separation of libraries such as org.jabref.model. Refs #110.

@stefan-kolb

This comment has been minimized.

Show comment
Hide comment
@stefan-kolb

stefan-kolb Mar 20, 2018

Member

@florian-beetz Did you see this issue yet? Maybe relevant.

Member

stefan-kolb commented Mar 20, 2018

@florian-beetz Did you see this issue yet? Maybe relevant.

@homocomputeris

This comment has been minimized.

Show comment
Hide comment
@homocomputeris

homocomputeris Sep 27, 2018

Maybe now it is more reasonable to transfer to Java 11 LTS?

homocomputeris commented Sep 27, 2018

Maybe now it is more reasonable to transfer to Java 11 LTS?

@Siedlerchr

This comment has been minimized.

Show comment
Hide comment
@Siedlerchr

Siedlerchr Sep 28, 2018

Contributor

Java 11 would definitely be our goal. However, as this builds on java module system introduced in 9, the key problems (some external dependencies) remain

Contributor

Siedlerchr commented Sep 28, 2018

Java 11 would definitely be our goal. However, as this builds on java module system introduced in 9, the key problems (some external dependencies) remain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment