RFR [9] Modular Source Code

[Magnus Ihse Bursie]

On 2014-08-18 16:15, Anthony Petrov wrote:
> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
>> libawt et al:
>>    The relation between libawt, libawt_headless, libjawt, libawt_xawt
>> and libawt_lwawt are hairy enough to make my brain curl up. I believe
>> there are simplifications to be made but I gave up trying to figure them
>> out.
>
> libawt contains code that is shared between all AWT lib 
> implementations. Depending on what mode/toolkit is requested, it loads 
> a specific variant of the awt native library, such as:
>
>  - libawt_headless - headless AWT implementation.
>  - libawt_xawt - XToolkit implementation (uses X11 for GUI)
>  - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI)
>
> Historically, we were able to choose between lwawt and xawt on Mac in 
> the past, but we no longer support or even build xawt on Mac. Also, in 
> the past there was MToolkit (which used Motif for GUI). Again, we no 
> longer support this toolkit. So, currently we always use xawt on 
> Linux/Solaris and lwawt on Mac. But since we still need to choose 
> between a real toolkit and a headless toolkit, we need the common 
> libawt library.
>
> libjawt is a helper library that implements JAWT API and is loaded by 
> applications that use the JAWT interface which allows them to get 
> direct access to the native AWT drawing surface and use native APIs 
> (e.g. OpenGL) to draw on the surface. This library isn't needed for 
> regular AWT/Swing applications.
>
> So I'm not sure if the current set of AWT libraries could be 
> simplified any further.
>
> Hope this helps.

Thank you for the clarification, it was very helpful!

While the set of AWT libraries probably cannot be simplified as you say, 
my gut feeling is still that the current layout of files on disk does 
not optimally match the actual libraries we build. Armed with the help 
of your description, I'll look into them once again and see if I can 
make that statement more concrete.

/Magnus