Re: <AWT Dev> java.desktop modularization

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: <AWT Dev> java.desktop modularization

Hontvári Attila

(cc-ing awt-dev)

I made a prototype, where java.desktop is split into 16+1 modules. java.swing is the largest module, its size is 6.9 MB, less than the one third of original java.desktop's size (23.3 MB). The prototype compiles without errors, but there are many runtime errors. If there is intention to include this into Java in the future, then I will continue the work.

Current list of modules (see dependency graphs at [4]):

  • java.awt (6.1 MB)
  • java.awt.toolkit (2.8 MB on Linux)
  • java.imageio
  • java.imageio.bmp
  • java.imageio.gif
  • java.imageio.jpeg
  • java.imageio.png
  • java.imageio.tiff (540 KB)
  • java.imageio.wbmp
  • java.laf.multi
  • java.laf.nimbus (1 MB)
  • java.laf.synth
  • java.laf.system
  • java.print (0,8 MB)
  • java.sound (1.2 MB)
  • java.swing (6.9 MB), but 2 MB of this is the Basic and Metal L&F
  • jdk.appletviewer
Most of the module names are self-explaining, except java.awt.toolkit (which is quite a bad name). This is needed because it is true that AWT strongly depends on Swing, but the problematic dependencies are only from the platform-specific toolkit implementations. Especially from the macOS implementation, where all of the UI controls are implemented using Swing. Therefore I extracted the toolkit implementations, and put them into this module. This is the prerequisite of separating Swing and Print from AWT. A non-GUI application, like a server which draws an image, only needs to require java.awt. (I didn't tried, but if AWT uses native input method and print GUIs on Windows, then it may be possible that we could remove the dependency on that platform. ) [3]

Small, but breaking API incompatibilites:
- AWT accessibility interfaces (AccessibleText and the AccessibleEditableText) referenced the Swing AttributeSet class
- AWT InputMethodContext had a method where the return type was Swing JFrame
I copied both methods, and modified them to use non-Swing parameter/return types, and made them default methods. New methods' implementations are calling the old methods' implementations (and the opposite) to ensure backward compatibility.

Other necessary API changes that aren't big problems I think, because their APIs are new in Java 9:
- The AWT AccessibleContext is annotated with @SwingContainer. So I moved the annotation to the java.beans package.
- The AWT Desktop.setMenuBar's parameter type is Swing JMenuBar. I changed the API and the only implementation (Mac OS X), but I couldn't test it, because I currently don't have access to a Mac.

The accessibility and input method methods mentioned above must be removed when the java.desktop modularization is introduced possibly in Java 10 (except if some new mechanisms are introduced in the future, which help maintaining compatibility). These methods must be deprecated one version earlier (Java 9?). Therefore I made a separate patch for Java 9 which includes the deprecations and the other changes to the code which were introduced only in Java 9 (Desktop, SwingContainer). [1]

Regarding the actual split, I couldn't make a readable webrev about the prototype, because the webrev includes a huge number of files that are moved, but not changed. Also after the 1700th file it stops.
I uploaded the source, .hg directory, and Linux x64 build in a large .tar.gz [2]. Consider it as a first attempt, there are many modifications which I would do differently now, for example the X11 TextArea reimplementation is unnecessary; and the patch isn't separated into small commits. If there is interest in this split, I will fix these problems and the runtime errors in it.



2017-01-30 17:57 keltezéssel, Alan Bateman írta:
On 30/01/2017 16:25, Hontvári Attila wrote:

Regarding to the reduction of the java.desktop module size:

Has Swing any circular dependency with other java.desktop parts? I know about only one, Desktop::setDefaultJMenuBar, which is only to be introduced in Java 9. If that dependency could be broken (by replacing the parameter type from Swing JMenuBar to AWT MenuBar), Swing could be extracted into a new module. Therefore the java.desktop size (28 MB including natives) would decrease by 7 MB.

And the non-default LookAndFeels (Nimbus, Windows, GTK, Synth, Multi, Aqua, Motif) could be also moved out to their own module, they are 2,5 MB.

I suspect there is a lot more to this once you dig into the details of the implementation. However, if you have the time and interest then maybe you would like to prototype the split and come back with your finding and results.