472 results about "Loader" patented technology

An evidence-based policy manager generates a permission grant set for a code assembly received from a resource location. The policy manager executes in a computer system (e.g., a Web client or server) in combination with the verification module and class loader of the run-time environment. The permission grant set generated for a code assembly is applied in the run-time call stack to help the system determine whether a given system operation by the code assembly is authorized. The policy manager may determine a subset of the permission grant set based on a subset of the received code assembly's evidence, in order to expedite processing of the code assembly. When the evidence subset does not yield the desired permission subset, the policy manager may then perform an evaluation of all evidence received.

Embodiments of the present invention relate to methods, systems and computer-readable media for external localization of a software product. This external localization involves loading a base product having one or more calls to an operating system (or an API) to load language specific data. The calls are intercepted after the resource is loaded into a Resource loader, and queried whether the resource is identified in a restricted resource list such as a code signed dynamic linked library. If so, the translated resource is loaded from a specified language package. The loaded, and translated, resource is then checked against validation rules (which are also protected in a code signed resource list) to see if it is safe to use. If the resource is not on the list or the translated resource is not safe to use, the original resource is simply transferred to the application without modification from the resource loader, i.e., loaded from the base language file. This generates a localized product using a limited set of language specific data covering most situations.

An object oriented mechanism and method allow allocating Java objects on a method's invocation stack in a partial compilation environment under certain conditions. Only the classes that are visible are taken into account when performing escape analysis in accordance with the preferred embodiments. In a first aspect of the invention, conservative assumptions are made to assure that objects are only allocated on an invocation stack when this can be proven safe by examining only those classes in the compilation unit. In a second aspect of the invention, the concept of visible classes is extended to include other classes that may be found from a user-defined classpath that matches the anticipated run-time classpath used to find classes during program execution. When stack allocation decisions for a method depends on such classes that are outside the compilation unit, two versions of run time code for that method are created. One version allocates all objects from the heap, whereas the other allocates some or all objects on the invocation stack. For each class outside the compilation unit that was examined when making stack allocation decisions for a method, information about the requisite class is stored with the method. At run time, the class loader verifies that the run time version of each requisite class matches all stored information about that class. If all information matches for all requisite classes, the version of the method using stack allocation is safe to use at run time. Otherwise, the method using heap allocation must be used.