Java Remote Method Invocation needs the ability to construct stub classes for
remote objects on the fly. The security of RMI can be improved if RMI can
generate the stub classes on the fly and define them to the system.
This functionality is needed even in the restrictive applet environment.

There is a more general need for the ability of Applets to define their own classes.
If it was possible, Sun and is licensees would not be the bottleneck in creating
customized mechanisms for class loading. There are many other useful forms of
loading classes the would allow classes to be preloaded or prefetched before they were
needed. A sophisticated applet could manage it own network latency and footprint.

The API of ClassLoader should be extended with a defineClass(String name, byte[] bytearray).
Subclasses, such as the AppletClassLoader, could restrict this function. Classes loaded
through this extended class loader would still be subject to the security manager
so this would not compromize the integrity and saftey of the local VM.

If possible this should be included in JDK1.1


Name: krC82822 Date: 10/15/2000


java version "1.2.2"
Classic VM (build 1.2.2_006, green threads, nojit)


While not strictly speaking a bug, this is a very annoying drawback.
Applets should be able to define classes from byte arrays, just as they
are able to download classes from untrusted web sites. This should be
trivial to implement--just skip the downloading step. All the same
security checks should be made on the byte code.

Someone reported this very problem in 1996, in bug report 1249673, which
I believe should be reevaluated (it is still open).

Some additional reasons this should be fixed:
(1) It is easy.
(2) It does not introduce new security issues.
(3) Currently, "defineClass" functionality is only available by subclassing
ClassLoader, which is not allowed in applets. By adding this functionality
to the Primordial ClassLoader, the need for subclassing ClassLoader diminishes,
which should lead to safer Java applications (as well as more Applet
functionality).
(4) It would make "self-extracting" applets possible, which moves
responsibility for technologies such as bytecode compression off the shoulders
of Sun, and other maintainers of ClassLoaders.
(Review ID: 110894)
======================================================================