SHORT SUMMARY: Improve CodeSource.matchLocation(CodeSource) performance

INDICATORS:  Large java.policy files which means some grant rules are subject
to DNS and rDNS calls which may be unnecessary.

COUNTER INDICATORS:
TRIGGERS: Large java policy rules or poor DNS/rDNS performance

KNOWN WORKAROUND: 
Seperate java policy files into smaller subfiles (per applet approach)
or sign applets to allow them run outside security sandbox. Cu was not
able to make suggested changes.

PRESENT SINCE: FCS

HOW TO VERIFY: 
Load  a simple applet while also have a large number of rules in 
.java.policy.
Cu sample policy file included in bugDB report.
e.g load http://java.sun.com/applets/jdk/1.3/demo/applets/Clock/example1.html 
and
see the performance delay for applet start time. Wireshark shows a series of 
DNS
calls being made which should be avoided with proposed fix *if* .java.policy 

updated to have better URL paths (more specific to each app instead of make 
rule
that contains root of server as URL codebase.

NOTES FOR SE:
Latest update to services : (see bugDB for full report)

I've a proposed patch under review with Dev engineers at moment. It 
optimizes
the performance of CodeSource.matchLocation(CodeSource) method. With patch 

rDNS request is last resort to help JRE  determine if two URLs match.

The two URLS under comparison are the host URL (of applet) and the various
grant codeBase URLS in the Cu's policy file. The JRE needs to determine if
any of them are a match and hence the DNS/rDNS requests. If we can 
determine
for any reason before DNS lookup that the CodeSources won't match, then
matchLocation should return false.

Mismatches occur when any of following conditions are met :
if protocols doesn't match;
if URL path doesn't match;
if URL anchor doesn't match;
if HostUnknown;
if URL1 != URL2 (rDNS used to test all various IPs)

The new patch means we avoid DNS if URL paths don't match. Cu will need to
implement change on their side though in order to have benefits from this.

Take for example a grant codeBase URL of "http://mvsdev.corpny.csfb.com/-"
and a host URL of "http://myserver.oracle.com/apps/"

Since the policy rule codeBase is recursive, it means DNS is involved since
we need to determine if the hosts are equal.

*however* if grantCode base was change to something more specific like :
 "http://mvsdev.corpny.csfb.com/appStore/-"
then no DNS is now involved. The URLS can never match.
i.e "appStore" != "apps"

Hopefully Cu can implement such a change on their end. In the meantime, 
I'll
continue patch review with Dev and hope to get a fix verification binary to
you in next 1-2 days.

REGRESSION: No.