87Re: [javax_compiler] Byte code compiler assembler and manipulator
- Dec 4, 2002
> I just read the JSR description (199), and it only speaks about sourcecode
> Do you think it's possible to add to the specification a byte code
> and/or an API to give to the users a convenient possibility to analyze,Before an assembler could be provided, you'd need a standard for JVM
> create, and manipulate (binary) Java class files ?
bytecode assembler format. Perhaps the Jasmin format could be adopted, but
there would need to be some official consensus on defining that language.
There hasn't been, of yet.
There is already at least one tool (BCEL, which you mentioned) to do the
latter bit. Perhaps that could become part of the language, too. Again,
though, it's not really related to a language compiler. It might be used in
the implementation of such a language compiler, but I see no connection in
terms of the API.
> There is already a bytecode manipulator in MS.dotNet, and Java developersof
> have to some external products (opensource or not).
> But in my opinion, a bytecode manipulator and/or assembler should be part
> the Java API, some developers and big companies are afraid to use toolsthat
> are not part of the specification.That's a very poor reason to expand the core API. If any such companies
truly exist (ie, ones that won't use code only because it's outside the core
API), then they will die soon and be replaced by companies with more
reasonable approaches on licensing and applying third-party code. Efforts
to stop this natural evolution of matters are misguided.
> Do you know if there is already a group working on that specification, doyou
> think it should be part of this JSR ?Not part of this JSR. If you think that the BCEL is useful enough to become
part of the core API, propose it as a new JSR.
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
- << Previous post in topic