=== [ The Java FAQ Daily Tips, weekly publication ] ===

Foreword: Excuse me for possible mistakes. English is not native language for me.

In this issue:

Hello dear friends!

Good to know: If your system does take in external XML data this security tip is for you!

While XML does not allow recursive entity definitions, it does permit nested entity definitions, which produces the potential for Denial of Service attacks on a server which accepts XML data from external sources. For example, a SOAP document like the following that has extremely deeply nested entity definitions can consume 100% of CPU time and a lot of memory in entity expansions.
<?xml version="1.0" encoding ="UTF-8"?>
<!DOCTYPE foobar[
<!ENTITY x100 "foobar">
<!ENTITY x99 "&x100;&x100;">
<!ENTITY x98 "&x99;&x99;">
...
<!ENTITY x2 "&x3;&x3;">
<!ENTITY x1 "&x2;&x2;">
]>
<SOAP-ENV:Envelope xmlns:SOAP-ENV=...>
<SOAP-ENV:Body>
<ns1:aaa xmlns:ns1="urn:aaa" SOAP-ENV:encodingStyle="...">
<foobar xsi:type="xsd:string">&x1;</foobar>
</ns1:aaa>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

A system that doesn't take in external XML data need not be concerned with issue, but one that does can utilize one of the following safeguards to prevent the problem:
New system property to limit entity expansion
The entityExpansionLimit system property lets existing applications constrain the total number of entity expansions without recompiling the code. The parser throws a fatal error once it has reached the entity expansion limit. (By default, no limit is set, because such a constraint would make the XML parser incompatible with the XML 1.0 specification.)

To set the entity expansion limit using the system property, use an option like the following on the java command line: -DentityExpansionLimit=100000

New parser property to disallow DTDs
The application can also set the http://apache.org/xml/features/disallow-doctype-decl parser property to true. A fatal error is then thrown if the incoming XML document contains a DOCTYPE declaration. (The default value for this property is false.) This property is typically useful for SOAP based applications where a SOAP message must not contain a Document Type Declaration.

This tip is based on:
http://java.sun.com/j2se/1.4.2/relnotes.html#jaxp

Java wimps please close your ears ... For the Java programmer who
thought he knew everything there was to know about Java, have a
look at the most advanced Java newsletter archived on the website
http://www.smotricz.com/kabutz Guess what, it won't even cost you
anything! Subscribe today - you won't be disappointed.

Question: What are enhancements were added to new javac since 1.4.2?

Answer: The following enhancements and bug fixes have been made to the javac source compiler in the Java 2 SDK.
RFE 4626998 implemented: Added -cp synonym for -classpath option to set classpath.
RFE 4515858 implemented: Added -Xbootclasspath/p: option to prepend to bootclasspath.
RFE 4253402 implemented: Added -Xmaxerrors and -Xmaxwarns to increase the number of errors and warnings printed by javac.

Also optimizations have been made to the core libraries to reduce startup time. For a small command line application, startup time has been reduced by roughly thirty percent; for a small Swing application, by fifteen to twenty percent.
In some rare situations, one optimization related to filename canonicalization may cause inconsistent views of the host platform's file system to be briefly visible to Java applications. The optimization caches, for a short time, the results of calls to File.getCanonicalFile() and File.getCanonicalPath(). If a file is moved by another application then the canonicalization result for that file may briefly differ from its true value, although attempts to open and access the file will succeed or fail as before. Applications should not rely on the presence or absence of such inconsistencies. If an application must disable this optimization for correctness purposes then the system property -Dsun.io.useCanonCaches=false may be specified.

Question: If I turn off daylight saving during an installation of Windows XP then Java runtime detects the platform time zone in the GMT offset format (e.g., "GMT+09:00"), not as a time zone ID (e.g., "Asia/Tokyo"). What is fix for that problem?

Answer: To fix this installation problem, take the following steps after the installation (unless you intend to turn off the setting):
1. Open Date/Time in Control Panel.
2. On the Time Zone tab, choose a time zone that observes daylight saving time (e.g., "(GMT-08:00) Pacific Time (US & Canada); Tijuana"), select the "Automatically adjust clock for daylight saving changes" check box, and press the Apply button.
3. Choose your time zone back and press the OK button.