Self Modifying Code

[Japcuh]

How do you write self modifying code in Java?

Japcuh
(Just Another Perl C Unix Hacker)
http://www.catb.org/~esr/faq/hacker-howto.htm#what_is
..0.
...0
000

 

[Eric Sosman]

How do you write self modifying code in Java?

What do you mean by "modify?" A Java program can
extend itself by loading new classes on the fly, if
that suits your needs.

 

[Roedy Green]

How do you write self modifying code in Java?

You can't modify a class once it has been loaded, but you can create a
similar class and load that.

You can do it by generating Java source and compiling that on the fly
to byte codes, or by generating JVM byte codes directly.

See http://mindprod.com/jgloss/eval.html
http://mindprod.com/jgloss/jasm.html
http://mindprod.com/jgloss/javacexe.html

 

[Kristian Larsen]

(e-mail address removed) (Japcuh) wrote in @posting.google.com:

How do you write self modifying code in Java?

You may want to check out the Java code generation library cglib:
http://cglib.sourceforge.net/

Best Regards
Kristian Larsen

 

[kjc]

No, but this could be done in Smalltalk blind folded.

 

[Roedy Green]

No, but this could be done in Smalltalk blind folded.

Is it a problem that you sometimes do it accidentally?

 

[Oliver Plohmann]

No, but this could be done in Smalltalk blind folded.

You can use Java Reflection which is Java's counterpart to Smalltalk's
perform: concatenate some strings to create an existing method name
and call that method. Or you can use the command pattern and add
commands as required to a list and execute them sequentially.

Cheers, Oliver

 

[Java Architect]

Check out this package:

http://jakarta.apache.org/bcel/

 

[Dave Monroe]

How do you write self modifying code in Java?

Japcuh
(Just Another Perl C Unix Hacker)
http://www.catb.org/~esr/faq/hacker-howto.htm#what_is
.0.
..0
000

It's nowhere near as easy as it is in Perl.

If you look at JDBC you'll see that there's a call to Class.forName()
to load the driver class. That may be of use to you. It's sort of an
'import' on the fly.

 

[Andrew Thompson]

It's nowhere near as easy as it is in Perl.

What's Perl got to do with it?

If your implication is 'Perl is better',
try this one..

How many lines of Perl would it take to
make a basic web browser?

[ Invalid groups ..'comp.lang.java.developer'
and 'comp.lang.java,comp.lang.java.misc,' all
dropped, F'Ups set to c.l.j.programmer.
For future reference, valid groups are listed here
<http://www.physci.org/codes/javafaq.jsp#cljh>

And to the OP, please do not cross-post..
<http://www.physci.org/codes/javafaq.jsp#xpost>
two groups might have been justifiable for this
post, but 5 is ridiculous. ]

 

[Thomas Weidenfeller]

If your implication is 'Perl is better',
try this one..

How many lines of Perl would it take to
make a basic web browser?

Surprisingly few I would guess. But that is IMHO not what this is about.

The OP didn't provide any context, so we are all guessing "how much"
self modification he wants/needs, or if he really needs self-modifying
code, or if running some on-the-fly created code would do for his
unknown purpose. We also have no hint how he defines self-modifying code
(changing something on assembler level, on byte-code level, or what else).

All we have is one hit-and-run post. I am to tired at the moment to
guess what it is what the OP wants/needs, so back to Perl ))

Perl has eval(), which is IMHO a much nicer way of running on-the-fly
created code than what need to be done in Java. In Java you need the SDK
(not freely re-distributable) instead of just the JRE installed (or
something like the apache byte code library), you need to mess with the
compiler invocation interface, and you need to mess with the class
loader. Yes, Perl is better, when it comes to the execution of
on-the-fly generated code.

Anyone interested in starting a JSR to add an eval() API to Java?


/Thomas

 

[Michael N. Christoff]

How do you write self modifying code in Java?

Japcuh
(Just Another Perl C Unix Hacker)
http://www.catb.org/~esr/faq/hacker-howto.htm#what_is
.0.
..0
000

Look up "Javassist" on google. Its what JBoss 4.0 uses to do dynamic aspect
weaving and dynamic remote proxy generation among other things. By the way,
for those who have used cglib, can you point toward some good online docs?
I have been unable to find any I found adequate. Javassist has pretty good
docs however.



l8r, Mike N. Christoff

 

[Joseph Daniel Zukiger]

Surprisingly few I would guess.

There's a basic webget in the appendix of the llama. A library
reference and four or five lines of readable code, as I recall. Just
dumps whatever the server sends you to the terminal, but it's a basic
browser.

But that is IMHO not what this is about.
Agreed.

The OP didn't provide any context, so we are all guessing "how much"
self modification he wants/needs, or if he really needs self-modifying
code, or if running some on-the-fly created code would do for his
unknown purpose. We also have no hint how he defines self-modifying code
(changing something on assembler level, on byte-code level, or what else).

All we have is one hit-and-run post. I am to tired at the moment to
guess what it is what the OP wants/needs, so back to Perl ))

And Java. And mostly the libraries, because that's where all the
interesting stuff is.

Perl has eval(), which is IMHO a much nicer way of running on-the-fly
created code than what need to be done in Java.

And Java now has EL. (Strange name. Can that be used without a
server?)

In Java you need the SDK
(not freely re-distributable) instead of just the JRE installed (or
something like the apache byte code library), you need to mess with the
compiler invocation interface, and you need to mess with the class
loader. Yes, Perl is better, when it comes to the execution of
on-the-fly generated code.

If you really want code generated on the fly, I agree, Perl's a bit
ahead of Java. But then Perl's always been a bit ahead of Java. That's
why the guys who created Java were able to learn from Perl's mistakes
(and make their own mistakes, but that's another story).

Anyone interested in starting a JSR to add an eval() API to Java?

I personally am not enthusiastic about languages that can compile on
the fly. I mean, I like FORTH, but you have to be able to control the
symbol space, and none of the common lanuages I've seen to this point
do that very well. (I accidentally built a dialect of FORTH that gave
me rudimentary symbol space control, but I haven't been able to get
back to that and make it useable yet.)

Most languages are designed to make it as easy as possible to access
the whole namespace universe, and that makes eval inherently insecure.

JDZ

 

[Andrew Thompson]

On 7 Jul 2004 18:50:24 -0700, Joseph Daniel Zukiger wrote:

There's a basic webget in the appendix of the llama. A library
reference and four or five lines of readable code, as I recall.

...damn-it! Looks like that was a poorly
chosen example, as I recall it takes around
57 lines in Java (though you get a GUI thrown
in with that, free), I had expected more in Perl
( even for a non GUI browser )..

Oh and yes, yes.. I am gonna completely
ignore the comments about how that was not
what this is about in any case. So there. ;-)

 

[Hong Jiang]

What's Perl got to do with it?

If your implication is 'Perl is better',
try this one..

Being able to write self-modifying code does not make a language
"better". Also, Dave did not imply this, I guess.

 

[Thomas Weidenfeller]

And Java now has EL. (Strange name. Can that be used without a
server?)

I think (don't take my word for it) EL is a JSP-only feature. It just
adds a few functions to JSP which allow for simpler scripting (I am not
an JSP guy, so I may be wrong). It is not that you can execute any kind
of Java code on-the-fly. It can do much less than Perl's eval().

If you really want code generated on the fly, I agree, Perl's a bit
ahead of Java. But then Perl's always been a bit ahead of Java. That's
why the guys who created Java were able to learn from Perl's mistakes
(and make their own mistakes, but that's another story).

I don't think it is a matter of being ahead. The two languages just have
different main application areas where one is "better" than the other.

I personally am not enthusiastic about languages that can compile on
the fly. I mean, I like FORTH, but you have to be able to control the
symbol space, and none of the common lanuages I've seen to this point
do that very well. (I accidentally built a dialect of FORTH that gave
me rudimentary symbol space control, but I haven't been able to get
back to that and make it useable yet.)

This is IMHO not a problem with compilation per-se. It is the same with
interpretation. SQL injection is a prime example. If you put unfiltered
user input in an SQL statement, the user might very well "own" the
database. The same with Perl , cgi script vulnerables are legendary,
thanks to programmers forgetting to check user requests.

Most languages are designed to make it as easy as possible to access
the whole namespace universe, and that makes eval inherently insecure.

You have that problem already in any Java application which fires up the
compiler on-the-fly and loads the resulting class. If the generated
source code somehow depends on user input, and if it isn't thoroughly
checked by the programmer, the user can inject code and get it executed.
No need to wait for eval() :-(.

/Thomas

 

[Mike Baranczak]

Well, there's this: http://www.beanshell.org
It's a lightweight scripting engine with a syntax very similar to Java.
The code is interpreted, not compiled, then again so are most scripting
languages. It also makes it very easy for the scripted code to
interoperate with the regular Java code (you can pass objects back and
forth, etc.)

-MB

 

[Joseph Daniel Zukiger]

On 7 Jul 2004 18:50:24 -0700, Joseph Daniel Zukiger wrote:



..damn-it! Looks like that was a poorly
chosen example,

Well, yes and no. If you look at the example and then look at how much
it takes to go from there to getting not just the page, but all the
images and other referenced objects, well, as Thomas kind of points
at, comparing them is more for the benefit of a different point of
view than for saying which is best.

as I recall it takes around
57 lines in Java (though you get a GUI thrown
in with that, free), I had expected more in Perl
( even for a non GUI browser )..

I think you end up having to load a graphics library (well, module),
typically TK. (Which brings us to TCL, which is also good for a
different point of view.) For what it's worth, IRRC, there is a
complete (minimalistic) graphics browser in perl available on CPAN as
a module.

Oh and yes, yes.. I am gonna completely
ignore the comments about how that was not
what this is about in any case. So there. ;-)

Oh, but should a browser be implemented in self-modifying code?

:->

JDZ

 

[Joseph Daniel Zukiger]

I think (don't take my word for it) EL is a JSP-only feature. It just
adds a few functions to JSP which allow for simpler scripting (I am not
an JSP guy, so I may be wrong). It is not that you can execute any kind
of Java code on-the-fly. It can do much less than Perl's eval().


I don't think it is a matter of being ahead.

Agreed. (Maybe I should have said, "perl had a head start.")

The two languages just have
different main application areas where one is "better" than the other.


This is IMHO not a problem with compilation per-se. It is the same with
interpretation. SQL injection is a prime example. If you put unfiltered
user input in an SQL statement, the user might very well "own" the
database. The same with Perl , cgi script vulnerables are legendary,
thanks to programmers forgetting to check user requests.


You have that problem already in any Java application which fires up the
compiler on-the-fly and loads the resulting class. If the generated
source code somehow depends on user input, and if it isn't thoroughly
checked by the programmer, the user can inject code and get it executed.
No need to wait for eval() :-(.

Oh, but eval is just so much easier to subvert! 8-*

 

[Entropy]

(e-mail address removed) wrote...

How do you write self modifying code in Java?

If it's truly self-modifying, good luck debugging it.