JAVAFX 8

[njss]

Any new developments in porting Jung to JavaFX 8? I've found some code for this but using old JavaFX 2.2...

Thank you in advance.

[jrtom]

No. The JavaFX-related code was an experiment, which we decided not to follow up on. The current version of JUNG does not include any JavaFX-related code, and I don't anticipate that changing any time in the easily foreseeable future, absent someone with JavaFX experience deciding to volunteer to help migrate the code over.

[aalmiray]

I'd love to help getting JUNG ready for JavaFX. There's the matter of compatibility as some APIs (Layout for example) make use of AWT classes such as Point2D and Dimension which would not be desirable as JavaFX provides it's own versions.

Would the team consider writing an abstraction over these types such that specific implementations (AWT, Swing, JavaFX, etc) can be based upon? This being a breaking change in the API would force the major version to bump to 3.

[jrtom]

@aalmiray We're not necessarily opposed in principle to introducing an abstraction layer, but that's another thing we've experimented with a while back (at that time, several years ago, it was to support SWT as well as AWT) and at least at the time, it turned out to be kind of a mess.

For what it's worth, there's already a 3.0 API in the works (we're replacing the graph data model with the Guava common.graph types) so we're already making breaking changes. If you'd like to go into some more detail about what you might expect such an abstraction to look like, we can discuss it further.

All that said: as the primary maintainer of this project at this time, I'm already pretty heavily committed, and am focusing the time that I have to spend on JUNG in making the existing 3.0 changes mentioned above. So if anyone wants the visualization system to be more overhauled to support JavaFX, I would need someone to take that on; I don't have the bandwidth.

[tomnelson]

Since Jung is made up of modules with somewhat limited inter-dependencies, It looks like it would be pretty easy to make a new jung-algorithms-fx where you use (the immutable) javafx Point2D and Dimension2D instead of the mutable awt equivalents, and also manage all of the places where the point.setLocation and setSize can no longer be called. Then make an entirely new jung-visualization-fx that depends on jung-algoriths-fx instead of jung-algorithms. I like that approach better than building some abstraction layer. We tried to make Jung modular for reasons like this one. There may be a need for a jung-io-fx, if IO is still needed by applications using jung-visualization-fx.