> 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. > > 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. > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA
Well, I must say that as of today we're not planning touch shared/common Hotspot logic at all as it requires a level of expertise we clearly do not have. In the near future we'll remain focused on removing Windows native sources and libraries we don't need, but later we may consider removing unused GC methods (though I really doubt it).
