1. When we moved from 1.5 to java 6 , the way in which jars are cached has changed.
in 1.5 , i was able to clearly identify my application from the cache. But in 1.6 , i see just folders named 0-63. We understand it is for security reasons.
But is it possible to go back to the old structure and still use javaws from 1.6 ??

2. Also i was reading about this feature : CD install of JNLP applications
http://docs.oracle.com/javase/1.5.0/docs/guide/javaws/developersguide/cdinstall.03.06.html

But does it work if i have versioning enabled in my JNLP
e.g line in my jnlp file
<jar href="jaxb-impl.jar" version="7.5.2.0.1" download="lazy"/>
I get such errors (because in my local disk(codebase attrib) , i had a jar named jaxb-impl__V7_5_2_0_1.jar)

1. When we moved from 1.5 to java 6 , the way in which jars are cached has changed.

in 1.5 , i was able to clearly identify my application from the cache. But in 1.6 , i see just folders named 0-63. We understand it is for security reasons.
But is it possible to go back to the old structure and still use javaws from 1.6 ??

No.

Cache internal details are not supposed to be exposed to the end user/app developer.
They can be changed any time for various reasons.

Why would you need to identify your app files in the cache?
May be very is better solution for your scenario.

The reason we want to identify the app files is to copy them to various desktops / profiles ( distributing to various vendors who access my app).
we shall lose this feature with jre upgrade on all user desktops.
Ours is a HUGE app accessed by many users but jnlp based.

If users from various geographocal locations start downloading the jars at the same time , it would result in
a. JNLP server crash
b. network clog
So if we copy the cache before a release , it helps us.
But we wont be able to do it anymore after jre upgrade.

I still get the same error inspite of setting the 2 properties
<property name="jnlp.packEnabled" value="true"/>
<property name="jnlp.versionEnabled" value="true"/>
<jar href="abc.jar" version="7.5.2.14.1" />

PAth:
abc__V7_5_2_14_1.jar
abc__V7_5_2_14_1.jar.pack.gz

java.io.FileNotFoundException: C:\Ram\JAR_TEST\signed\abc.jar (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

From exception tab
com.sun.deploy.net.FailedDownloadException: Unable to load resource: (file:C:/Ram/JAR_TEST/signed/abc.jar?version-id=7.5.2.14.1, 7.5.2.14.1)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)