<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=KOI8-R" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 5/24/2010 11:17 AM, David Herron wrote:
<blockquote
cite="mid:AANLkTinti_9Wy9uSlY8A90bZKhHyzD6OYkBYku_2qCIL@mail.gmail.com"
type="cite">On Mon, May 24, 2010 at 10:27 AM, áÎÄÒÅÊ íÉÛÁÎÉÎ <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:amishanin@swemel.ru">amishanin@swemel.ru</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br>
<br>
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:<br>
š š š š- all native source code targeting Windows and Linux (yes, I
know, Linux and Solaris native sources have much in common but still)<br>
š š š š- JRE classes and namespaces we do not use at all (i.e. java.sql
or jaxp)<br>
š š š š- 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)<br>
<br>
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 :-)<br>
<br>
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.<br>
</blockquote>
</div>
<br>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>- David Herron</div>
<div><a moz-do-not-send="true" href="http://davidherron.com">http://davidherron.com</a></div>
<div><br>
</div>
<div><br>
</div>
<div>PS I'm surprised you didn't mention CORBA as one of the things
to ditch...</div>
<div><br>
</div>
</blockquote>
<br>
As a side note on David's point:šš I'm pretty sure that having a
working SUBSET of the full JDK is much more acceptable than having
either a SUPERSET or disjoint Set.š That is, if you can detail ahead of
time what sections of the "Zircon JDK" won't work for your userbase,
they'll be much more forgiving than if you do something like replace
sections of the JDK with other (non-compatible) implementations/designs.<br>
<br>
As far as the VM goes (my area), it is possible to remove a GC method
(CMS, G1, etc.), but it's not easy.š Removing anything else from the VM
is going to be a huge amount of work, and I'd strongly advise you not
to try.š More importantly, in the VM, removing things without a /very/
deep understanding of what you are doing is very likely to severely
impact performance.š I realize you had focused on portions of the
Library section of the JDK, but be aware that the JDK is not just the
Libraries. <br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA</pre>
</body>
</html>