Java and Memory Protections [LWN.net]

Java and Memory Protections

Posted Nov 22, 2006 18:19 UTC (Wed) by iabervon (subscriber, #722)
In reply to: Java and Memory Protections by NAR
Parent article: Virtual Machines and Memory Protections

Dynamic generation of Java bytecode is actually quite common; that's how applets actually work. The plugin, running in a JVM, downloads code from the internet as a sequence of bytes, and calls the library method to read the memory as classes. Sure, it's not generation of bytecode from scratch, but it is pulled out of nowhere with respect to memory protection and certainly ahead-of-time compilation.

(Log in to post comments)

Java and Memory Protections

Posted Nov 24, 2006 18:45 UTC (Fri) by ttfkam (guest, #29791) [Link]

This is incorrect. This is not how applets work. Applets use classloaders (network classloaders in this case) exactly like any standalone Java application might.

JSPs have sort-of done this for years by compiling whenever the source doc is modified. Another example would be the "translets" created from XSLT stylesheets tranformations by the XSLTC.

A better example of dynamic code generation would be frameworks that implement EJB3 and read information from annotations to generate code that fits those aspect-oriented patterns.

But that's higher level. From the implementation point of view, dynamic code generation is implemented from libraries like ASM, JavaCC, cglib, etc.

Java and Memory Protections

Posted Dec 3, 2006 12:54 UTC (Sun) by fjalvingh (guest, #4803) [Link]

You are both right. A ClassLoader is used to create the class. But the classloader used for Applets (which is a a standard one) indeed merely loads a stream of bytes and instantiates these as a Class using a ClassLoader base method [ Class defineClass(String name, byte[] b, int off, int len)].

In Java it is trivial to write and execute your own byte code from within a program; whole libraries exist to help you doing it (BCEL, ASM). I used this extensively in many programs to speed up scripting stuff or parameterized logic by compiling it into a class (which will then be JITted by the Java runtime).

Anyway, the fact that Java code can do that has nothing to do with the article's subject which has to do with actual executable content for a system processor...