# `net.jini.loader`
Apache River v3.0.0 Release Notes

### Description

The `net.jini.loader` package and its subpackages provide APIs related to dynamic class loading and, in particular, preferred classes.

### Changes since the v2.2.0 release

- [RIVER-396] - PreferredClassProvider classloader cache concurrency improvement

  ### Changes since the v2.1.1 release

- [RIVER-9] - PreferredClassLoader should try to avoid making a direct check against the first URL

### Changes since the v2.0.1 release

`PreferredClassProvider` constructors now require a permission

  The constructors of `PreferredClassProvider` now check that the current security context has the permission `RuntimePermission("createClassLoader")`, and they throw a `SecurityException` if that check fails. The primary consequence of this change is that the protection domain of a subclass of `PreferredClassProvider` must have this permission in order for the subclass to be instantiated. Instances of `PreferredClassProvider` are typically only instantiated as part of the internal process of looking up and initializing the `RMIClassLoader` provider, so this change is unlikely to affect the permission requirements of classes other than `PreferredClassProvider` subclasses.

New `PreferredClassLoader` constructor with `URLStreamHandlerFactory` parameter

  `PreferredClassLoader` has a new constructor, with a `URLStreamHandlerFactory` parameter that can be used to control the `URLStreamHandler` used when the loader creates new `URL` objects (which it does in order to load classes and resources from JAR files, by using the `"jar"` URL scheme). This new constructor is intended to parallel the superclass `java.net.URLClassLoader` constructor that has a `URLStreamHandlerFactory` parameter.

New `PreferredClassProvider` `protected` method `createClassLoader`

  `PreferredClassProvider` has a new `protected` method, `createClassLoader`, which can be overridden by subclasses to customize the creation of new class loaders created by the provider.

### Known Issues (& Workarounds)

Difference in behavior between `PreferredClassProvider` and the default `RMIClassLoader` provider

  `PreferredClassProvider` has the following difference in behavior from the default `RMIClassLoader` provider even when no preferred lists are used:

  For a given class loader, `PreferredClassProvider.loadClass` assumes that any class that can be downloaded from the codebase annotation for classes defined by the loader can always be loaded by the loader. Therefore, when attempting to load a class from a given codebase, if the current thread's context class loader or one of its ancestor loaders has that codebase as its annotation, then `PreferredClassProvider.loadClass` will only attempt to load the class from that loader instead of from one of its own loaders that downloads from the codebase.

  The default `RMIClassLoader` provider does not make this assumption; its `loadClass` method will attempt to download a class from a codebase even if a class loader with that codebase as its annotation (such as the current thread's context class loader or one of its ancestors) could not load the class.

  `PreferredClassProvider.loadClass` makes the assumption in order to avoid incorrectly returning a preferred class defined by a different class loader (and thus with a different runtime type) than that of a locally available class with the same name and codebase annotation.

  In versions of the Norm implementation of the River lease renewal service prior to v2.0, there are some classes in `norm-dl.jar` that are not in `norm.jar`, and thus Norm will fail to start with `PreferredClassProvider` configured as the `RMIClassLoader` provider. This problem can be worked around by using the default `RMIClassLoader` provider instead of `PreferredClassProvider`, or by using the current version of Norm.

Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.