RFR [9] Modular Source Code

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Aug 25 09:14:04 UTC 2014


On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
> On 2014-08-18 16:15, Anthony Petrov wrote:
>> 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.

This is my suggestions based on what I found when trying to remove the 
last unnecessary entanglement. Note that all paths are relative to the 
java.desktop module, and  that I have at this stage only looked at 
compiled sources (*.c), not header files.

* The following files are in the windows directory tree, but are 
explicitly excluded on Windows. Thus they will never be built, and 
should be removed instead:
   ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
   ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
   ./windows/native/libawt/sun/windows/WBufferStrategy.cpp

* The following file is in the share directory tree, but is only used on 
Windows. It should be moved to the corresponding windows directory instead:
   ./share/native/libawt/sun/java2d/ShaderList.c

* The following directory is in the unix directory tree, but is only 
used on Solaris. It should be moved to the corresponding solaris 
directory instead:
   ./unix/native/libawt/sun/java2d/loops

* The directory ./unix/native/common/sun/awt contains five more or less 
unrelated .c files. Three of them are only used in libawt_xawt, and 
should be moved there:
   ./unix/native/common/sun/awt/awt_Font.c
   ./unix/native/common/sun/awt/fontpath.c
   ./unix/native/common/sun/awt/X11Color.c
Of the remaining two CUPSfuncs.c seems correctly placed, since it is 
shared between libawt_xawt and libawt_lwawt. However, I'm wondering 
about initIDs.c. It is compiled in libawt as well as libawt_xawt, but 
when I checked some random functions, they are exported (via the 
mapfile) for libawt only. So I believe it is a mistake to include it in 
libawt_xawt, and that it should be moved to the libawt directory. This 
will need verification from someone on the AWT team.

* The directory ./unix/native/libjawt is included in libawt_xawt (and in 
libjawt, of course). This seems suspicious to me. There is just a single 
file with a single function, JAWT_GetAWT(), which is exported in libjawt 
(via a mapfile), but not in libawt_xawt. I believe it is a mistake to 
include it in libawt_xawt. This will need verification from someone on 
the AWT team.

* All of the awt-related directories (libawt_* and common) include an 
unnecessary extra layer, the "sun" directory. It is not needed anymore, 
and just makes all paths extra long. I suggest that we remove that layer 
and move everything up one step.

* The makefiles include too specific directories. Instead of including 
e.g. ./*/native/common/sun/java2d/opengl and 
./*/native/common/sun/java2d/x11, we should just include 
./*/native/common/sun/java2d. This level corresponds to a logical 
grouping of the source code, and not the directory structure in that 
grouping.

* The file ./windows/native/common/awt_makecube.cpp is a bit strange. It 
is not a shared file; instead it's a stand-alone binary with a main() 
function. It is not compiled by any makefile targets. If this file is 
actually used, I suggest moving it to a better location 
(windows/native/launchers?), and starting to compile it with the build. 
(Stuff that's not built regularly is doomed to bit rot.) It if is not 
used, I suggest we remove it.

* And as I stated before, the medlialib directories are typically not 
used by libawt and friends. It is used by libmlib_image and 
libmlib_image_v, and should move away from the awt directory.

/Magnus



More information about the build-dev mailing list