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.

  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.
>