JDK/JRE has been using the time zone data at <java.home>/lib.zi, which is compiled from Olson zoneinfo data via javazic, for j.u.TimeZone since JDK 1.4.0 [1].
JSR310 has introduced in its own time zone data file/format <java.home>lib/tzdb.jar to provide the time zone data for its new java.time date-time classes, though the time zone data source is the same Olson tz data (now the IANA Time Zone Datebase, TZDB).

So we now end up with two different time zone data files in different format (from the same time zone data source) to support two sets of date-time APIs (java.util date-time classes and java.time date-time classes), which definitely will add the maintenance burden going forward, given the fact that we will have to update/distribute the latest tzdb data in JDK/JRE periodically [2].

Also the current way the time-zone data is being distribute/installed (at <java.home>/lib.zi, as individual file for each time zone) has been a footprint concern for some configurations, especially the small embedded environment. The JEP151 [3] was originally submitted to propose to store the time-zone data more efficiently into a single compressed file. The JEP 151 has been withdrew since, with the assumption that JDK 8 may replace the "zi" data with the much smaller JSR310 tzdb data file.

As mentioned in JEP151, current installed "zi" directory probably takes up 1M of disk-space with the 0.5k default file-system-block-size. Even with the proposed "store in one single compressed file" approach, it will still take about 250K space for all tzdb data in "zi" directory. JSR310 tzdb data file however is much smaller. It is around 40K for compressed and 100k uncompressed, with the same tz data.

The prototype implementation [4] indicates that it is possible to convert the JSR310 tzdb date completely (bits to bits compatible) into the internal data structure j.u.TimeZone needs for its functionality, at runtime Though there is an expected performance cost for the first time tzda access, as showed below.

Here is the "original" JDK data, the time is measured in ns/1000 (except the last one), so the first invocation of TimeZone.getTimeZone() takes about 8 ms

TimeZone.getTimeZone()[1]=8023
TimeZone.getTimeZone()[2]=163
TimeZone.getTimeZone()[3]=111
TimeZone.getAvailableIDs()=2097, total=616
TimeZone.TotalTZ()=40 (ms)

vs the proposed sharing approach

TimeZone.getTimeZone()[1]=24574
TimeZone.getTimeZone()[2]=1207
TimeZone.getTimeZone()[3]=955
TimeZone.getAvailableIDs()=1560, total=610
TimeZone.TotalTZ()=121 (ms)

in which we see a 8 ms vs 24 ms slowdown, an expected "regression" and a typical cost of space vs speed trade-off. This is a one-time slowdown, all the tzdb data will be cached, so any following access will be a hashmap "get" access (The [2], [3] data above is the first access as well, for different time zone, they don't have the file reading, searching cost)

(Basically "zi" saves the zone data for one zone in a single file, so you only need to read in one small file for that particular zone. tzdb, however reads in all data at the beginning of the jvm startup, so there is a "read-in" cost. And transfer from tzdb's format to "zi" format takes some time)

JSR310 project team believes the benefits of sharing a single time zone data inside a single JDK/JRE is worth the performance cost mentioned above. Therefor we are proposing to replace the existing jdk timezone data at <java.home>/lib/zi with the JSR310's tzdb data file to share a single tzdb data for both j.u.TimeZone and java.time date-time classes.

[1] https://jbs.oracle.com/bugs/browse/JDK-4230123
[2] http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html
[3] http://openjdk.java.net/jeps/151
[4] http://cr.openjdk.java.net/~sherman/jdk8_threeten/tz_share/