RFC: Make javax.jnlp package visible to javac

[Joe Darcy]

Omair Majid wrote:
> Andrew John Hughes wrote:
>> 2009/6/4 Omair Majid <omajid at redhat.com>:
>>> Hi,
>>> 
>>> Sun's documentation states that javac should be able to compile
>>> code that uses javax.jnlp once jnlp.jar is added to the classpath
>>> [1]. 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 [2].
>>> 
>>> 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
>>> visible.
>>> 
>>> Ok to commit?
>>> 
>>> Cheers, Omair
>>> 
>>> 
>>> [1] 
>>> http://java.sun.com/javase/6/docs/technotes/guides/javaws/developersguide/examples.html#Introduction
>>> 
>>> 
>>> [2] http://andrew-haley.livejournal.com/695.html
>>> 
>> 
>> Looks good to me (though seems strange the Makefile is under
>> docs...).
> 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

Hello.

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:
    http://blogs.sun.com/ahe/entry/b86_compiler_fixes

 > "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
 > classes.
 >
 > 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
 > warning.
 >
 > 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
 > version."


-Joe