(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.
Attila
[1] http://kafa.flyordie.com/~attila/OpenJDK/desktop_split_prepare/
[2]
http://kafa.flyordie.com/~attila/OpenJDK/desktop_split_prototype/split_prototype_20170302.tar.gz
[3]
http://kafa.flyordie.com/~attila/OpenJDK/desktop_split_prototype/java.awt.toolkit.png
[4]
http://kafa.flyordie.com/~attila/OpenJDK/desktop_split_prototype/gengraph/
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.
-Alan.
