Basic Customization > Windchill Customization Basics > Managing Customizations > Best Practices for Customizing Files Supplied by PTC > Managing Client JAR Files > Overview of Client JAR Deployment Approach > Logical JARs
  
Logical JARs
The concept of a “logical” JAR was introduced to Windchill in R7.0. Each logical JAR is actually composed of four JARs, in addition to any external dependencies it might have, e.g. to 3rd-party jars. The components of a logical JAR are shown in the figure below.
In this figure, the bolded labels denote role names for each component JAR whereas the italicized name denotes the actual name of the JAR. Thus for a logical JAR named “MyApplet”, for instance, the components would be MyApplet.jar, MyAppletCust.jar, MyAppletDSU.jar, and MyAppletFCS.jar.
* 
The classloading precendence is from left to right in the figure, so that customization JARs override DSU JARs, which in turn override original distribution JARs.
Head JARs only include manifests declaring the component and other JARs upon which they depend, as well as a JAR index in cases where the head JAR is the top-level JAR for an applet. PTC distributions leave customization JARs empty, as these are for customer additions and overrides (e.g. to resource bundles). DSU JARs are left empty until a maintenance release provides additional files to target client(s) and/or newer versions of files already present in the corresponding FCS JAR. The FCS JAR contains all the original files required by a module at FCS (first customer shipment). The head JAR may list additional JARs upon which it is dependent after its own components.
* 
The usage of “DSU” comes from the fact that, pre-R7.0, maintenance releases to Windchill were delivered in Downloadable Software Updates.