Andrey,
Unless you plan on only doing this once, there will be a limit on what
you can do without this becoming a maintenance nightmare.
In simplistic terms with the Hotspot code base for any OS you don't
support you can delete any directory with that OS in its name. This
includes the src/os/* directories and the src/os_cpu/* directories and
the make/* directories. You can then do the same thing for any cpu
architectures you don't support.
Unfortunately a lot of the supposedly common/platform-independent code
in the VM is polluted with platform specific ifdefs. So if you wanted to
go further you'd then go through and delete all the irrelevant ifdef'ed
code - but that's the part that would then become a maintenance nightmare.
Note that in the JDK the Solaris and Linux code is shared (and in the
solaris directory) with a smattering of ifdefs.
With regards to the OpenJDK libraries you may well be able to prune
whole package branches, but you might find some non-obvious interactions.
But really I don't see much point in exerting effort to achieve the
above, when you could just prune the list of files to be verified, and
the verification process can then ignore irrelevant ifdef'ed code.
If you want to go further and try to prune parts of the VM you don't
use, then it becomes an entirely different matter. I would not recommend
attempting this.
By the way, I think there should be very little tinkering with Makefiles.
Cheers,
David Holmes
Андрей Мишанин said the following on 05/25/10 03:27:
Hi everyone. My name is Andrey, I'm from Russia. Our company is building it's
own operating system based on Solaris 10 with Trusted Extensions (it is named
Zircon) and we've chosen OpenJDK 7 as a main platform for our application
development. Our current goal is to create a specialized version of JDK
targeting solely Zircon with everything we don't need thrown out (you may think
of it as an embedded version of JDK, however it isn't). The main task is to
reduce overall amount of the source code (not the size of the binary image) as
later it will be analyzed and certified for use in government bodies. Long
story short: the more source code we have to submit for analysis, the more it
will cost.
So far I have managed to successfully build the latest source code snapshot
(dated May 13) on Zircon and verified that all of our Java applications run on
OpenJDK without any problems. So now I need to figure out how I can remove
those chunks of source code we don't need. The usual suspects are:
- all native source code targeting Windows and Linux (yes, I know,
Linux and Solaris native sources have much in common but still)
- JRE classes and namespaces we do not use at all (i.e. java.sql or
jaxp)
- some of JRE classes we do not need (for example we have settled on Nimbus
as a default look and feel for all our GUI applications, which means we do not
longer need Motif or Metal L&Fs)
So I'd be grateful if you could describe an overall strategy of removing
OpenJDK parts I've mentioned in the previous paragraph with as little hassle as
possible. Well, may be not a complete strategy, but some hints and best
practices will be greatly appreciated :-)
P. S. I expect lots of tinkering with Makefiles and another files in jdk/make
to be involved, so it'd be great if you could give me a link to docs or
description of those.
