Reducing overall amount of OpenJDK source code

David Herron davidh at
Mon May 24 18:17:18 UTC 2010

On Mon, May 24, 2010 at 10:27 AM, Андрей Мишанин <amishanin at>wrote:

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

An obvious consideration is whether you want the result to be certifiable as
Java Compatible with the trademarks .. you'll have to pass the TCK and other
requirements .. those tests include whether you have a complete set of
API's.  This includes java.sql and jaxp ... hence the direction you just
laid out won't be certifiable.

But .. pragmatism says that the existence and success of Android shows that
the world is willing to adopt a near-Java platform that doesn't meet
the compatibility requirements.

- David Herron

PS I'm surprised you didn't mention CORBA as one of the things to ditch...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the build-dev mailing list