Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • B bjgf
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Issues 124
    • Issues 124
    • List
    • Boards
    • Service Desk
    • Milestones
  • Jira
    • Jira
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • BlueJ
  • bjgf
  • Issues
  • #1267

Closed
Open
Created Jan 20, 2020 by Neil Brown@nccbMaintainer

[BLUEJ-1293] Fully modularise BlueJ

With the move to Java 11+, we can potentially switch BlueJ over to use the new module system. Based on a brief exploration of this, it should be possible, although we have decided against for now. The main hitches were:

  • We need several add-opens flags to help with accessing some module internals. At the time the list was: --add-opens javafx.graphics/com.sun.glass.ui=bluej.boot --add-opens javafx.graphics/com.sun.javafx.tk=nsmenufx --add-opens java.xml/com.sun.org.apache.xerces.internal.parsers=xom
  • The Boot module seems to cause problems. Its class-loader mechanism was switched to module-finder, but it seems to cause problems when Boot's required modules (e.g. JavaFX) overlap with the ones it dynamically loads. The best thing to do may be to scrap Boot, and move the module path to the launchers for the different operating systems.
  • We may need to rearrange how we make JARs, as some of the JARs have packages split across them. I think nowadays we may only need bluejext2.jar, with everything else in bluej.jar? We also need to be mindful of Greenfoot, though.

Issue metadata

  • Issue type: Bug
  • Priority: Medium
Assignee
Assign to
Time tracking