Subject:	Automatic, Transparent, Remote Fetching and Loading of Classes in a Legacy Modules - How Feasible?
	Date:	2007-03-09 23:51:14
	From:	simonreid
having just taken a lot longer than expected to get my head around printing in the JDK, i am sure removing deprecated apis would make it simpler to learn new parts of the JDK ... great! ... but i never want software i have written and released to suddenly stop working ... no customer satisfaction there! ... so, if deprecated apis are removed, there needs to be a simple way for a newer JVM that load classes that use the deprecated apis to 1) recognize they it has done so, and 2) get the legacy versions it needs. i am no expert here, but i imagine the JVM could check the method signatures on classes in all packages in the JDK to determine if legacy versions are required. (would this cause unacceptably slow loading?) assuming a modular JDK becomes reality, if legacy versions are required, the JVM would request them remotely from Sun and download then in jars using the standard module system. if the internet is not accessable, the JVM would have to give intelligible notification to the user advising them that they need to connect to get the "update" ... the legacy jars would contain the original classes from an early version of the JDK compiled with that version of the JDK - these would be loaded instead of the newer versions. the extra download would be an inconvenience to the user, but once the correct version of the class had been obtained it would behave exactly as it did when the developer build and tested the app - that is crucial. although it might seem more appealing for the JVM to perform some transforming magic on loading classes converting them to use new APIs (saving a download and possibly doing some optimizations) that could introduce a whole range of potential bugs and subtle differences in behavior not experienced by the developer when they built and tested the original software ... i believe a well-know desktop operating system owed a lot of its instability to transforming itself to run in various backward compatibility modes ... i would hate the JVM to get the same reputation .. obviously, developers could use things like Jackpot to transform their own old source code to use new APIs as they develop new apps because they can compile, test and debug it before they is released ... i would really like to see cruft removed from the "core" JDK, but only if there is a simple, reliable and standard way for newer JVMs to automatically access the legacy versions of classes using the same module system used to access other "non-core" JDK components ... if it cannot be made automated and transparent to the user, the deprecated APIs should never be removed ... if it can, then why not remove deprecated APIs immediately? Does this sound feasible?