It seemed like a good idea to temporarily place the UPX and the 7-Zip SDK compression utilities in the deployment workspace while RE is booked up with Mercurial transition and other work, but even temporary placement in one of the SE workspaces is creating hazards, chiefly that in some cases the build make files have to assume deploy workspace path: an assumption that may not hold up at various Sun sites or in novel settings.So this CR is intended to add some urgency to finding permanent homes for UPX and 7-Zip SDK.The additional reason for this CR is to avoid various complications to do with having UPX and/or 7-Zip in a deployment work space in conjunction with any transition of deployment to open source and involving licensees who may not be comfortable with using open source.

The UPX bundle used by Java Kernel is a Windows-specific binary bundle and would be easily accessible with a path such as ${ALT_DEVTOOLS_PATH,$DEVTOOLS_PATH}/upx/upx301w.zip

The 7-Zip SDK is portable and could easily be accessible with use of an existing or new make variable made to point to a shared path like this:
   /java/devtools/share/7-Zip/lzma449.tar.bz

Note that UPX and 7-Zip usage are goverend by formal reviews #7308 and #7309 respectively.
A "README" with this info could be supplied to sit alongside the two bundles above to alert developers to usage restrictions. And this is the rationale for leaving these packages in "bundled form": to give developers the opportunity to avoid mistakes including improper use of LGPL'd code.