RFC: Make javax.jnlp package visible to javac
Joe.Darcy at Sun.COM
Mon Jun 15 14:45:12 PDT 2009
Omair Majid wrote:
> Andrew John Hughes wrote:
>> 2009/6/4 Omair Majid <omajid at redhat.com>:
>>> Sun's documentation states that javac should be able to compile
>>> code that uses javax.jnlp once jnlp.jar is added to the classpath
>>> . IcedTea6, however, has no jnlp.jar, and javax.jnlp.* classes
>>> are already in rt.jar. It turns out that you have to use 'javac
>>> -XDignore.symbol.file OnlineTest.java' for this to work .
>>> The attached patch adds javax.jnlp to NON_CORE_PKGS list, making
>>> it visible to javac.
>>> ChangeLog: 2009-06-04 Omair Majid <omajid at redhat.com>
>>> * patches/icedtea-webstart.patch: Make javax.jnlp classes
>>> Ok to commit?
>>> Cheers, Omair
>>>  http://andrew-haley.livejournal.com/695.html
>> Looks good to me (though seems strange the Makefile is under
> I could move the Makefile in the patch ;)
>> Did we ever work out if there was a good reason for keeping this
>> symbol mapping stuff?
> Nothing formally. If I recall correctly, Andrew Haley mentioned that
> it might make javac faster. Presumably anything not visible to javac
> is not really part of the Java API and there should be no need for
> programmers to use those classes (but this doesnt hold true for some
> parts of IcedTea).
> Cheers, Omair
The ct.sym file is a mechanism used be javac for a variety of reasons,
including to serve as a stepping stone toward modules. Peter Ahe wrote
about it his blog entry:
> "Finally, I would like to mention that we have made a great
> improvement for cross-platform compatibility. Previously, all
> packages in rt.jar are visible at compile time. However, many of the
> packages in that file are Sun proprietary unsupported implementation
> details. Some come to mistakenly rely on this which can cause
> problems when upgrading from one version of Sun's JDK to another (as
> we don't make any guarantees). Also, it can cause problems when
> running on other vendors' platforms as they might not have these
> To address this problem, undocumented packages (that are new in
> Mustang) will not be visible at compile time. For example, while the
> package sun.reflect.misc is in rt.jar, javac will not be able to see
> it. Later we hope to emit warnings for packages that are undocumented
> but visible because of legacy from older releases. For example, the
> package sun.io will remain visible but use of it may lead to a
> To hide these packages, javac will not be reading rt.jar anymore.
> Instead it will read a symbol file (in some unsupported unspecified
> format: we are planning on adding a real module system in Dolphin).
> This symbol file idea was pioneered by Tom Ball to speed up
> compilation (and save memory). However, while this helps in scenarios
> like app servers, Jackpot, and NetBeans, it may not do much for
> regular batch compilations. Once we have done some profiling of the
> file manager in javac, I hope it will be much faster than the Tiger
More information about the distro-pkg-dev