this article introduces readers to bytecode generation and shows how to inject generated bytecode into a jvm runtime. after reading this article generating a java class wont be any harder than creating an xml document with the dom api.
over last couple of years, bytecode generation has gained significant momentum. many tools generate bytecode instead of source code to obviate the compilation step and simplify the injection of generated code at runtime.
theres a number of bytecode-generation libraries with bcel (byte code generation library) being the most renown and probably most powerful. its used by tools such as xalans stylesheet compiler and mercury interactives topaz j2ee probe.
bytecode vs source generation
you may ask: "why bother with bytecode generation if i can produce java source?" ultimately, its your call what technique to use. for example, some people create xml documents with println(), others use the dom api. keep the following considerations in mind: with jad, jadclipse or dj java decompiler (see resources) a .class file is an open book as .java file. but read-only. so theres no need in (and actually no place for) formidable headers like "generated by xxx - do not edit!" there is an additional compilation step if you produce source instead of bytecode. compilation at runtime is a real big headache, especially if you dont control the target jvm. the amount of java code you have to write to produce java source wont be significantly less than the amount of java code for bytecode generation. actually, it may be more. using different template engines has its own vices. first of all generation logi... 下一页