Hi,
> From: Aaron Mulder [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 04, 2001 3:47 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [half-off-topic] Java Compilers
>
>
> If you haven't seen it already, there's an article on the Swing
> Connection on creating dynamic event listeners or some such which seems to
Could you give me url please?
> have been the basis for the Dynamic Proxy support in JDK 1.3. It has
If I'm thinking about the same thing, that's what I'm scared of - I want to
"staticize" things, not to make them more dynamic.
Consider the following example:
Program - let's assume it's HTTP server. The server calls "cache" for
RuleProcessor object, which has a single method like "boolean
clientAllowed(RequestData rd)". Then, Cache checks the file "rules.xml" - if
it was modified recently (or not read before), it's loaded, converted from
xml to source implementing the interface specifing method clientAllowed,
then compiled. Finally Server gets RuleProcessor compiled from xml file
(possibly using xsl transformation, but that's not my area). The point is,
rules.xml is interpreted, and then compiled, only after changes are
detected, then Server gets object running extremely fast compared even to
most optimized data structures.
Then again, maybe the savings aren't that much? Correct me if I'm wrong?
For example:
<access-rules>
<access-rule>
<uri-mask>/localonly/*</uri-mask>
<allow-ip>1.2.3.4</allow-ip>
<allow-ip>1.2.3.5</allow-ip>
<deny-all/>
</access-rule>
<access-rule>
<uri-mask>/*</uri-mask>
<deny-host>*.crackers.net</deny-host>
<allow-all/>
</access-rule>
</access-rules>
Could be compiled into:
public class Xxx implements RuleProcessor
{
public boolean clientAllowed(RequestData rd)
{
if( rd.getUri().startsWith("/localonly/")
{
if( rd.getIp().equals("1.2.3.4") )
{
return true;
}
//...
return false;
}
else if( rd.getUri().startsWith("/")
{
if( rd.getHost().endsWith(".crackers.net") )
{
return false;
}
return true;
}
else
{
return false;
}
}
}
I'm attaching minimalistic proof-of-concept implementation.
> source code for generating classes on the fly that implement arbitrary
> interfaces, including some generic routines for writing useful bits of
> bytecode. If your goals are limited enough in scope, you may want to skip
> the source code and just spew out bytecode directly based on the XML file
> you're reading.
> Also, I have JDK 1.2 implementation of Dynamic Proxies that you're
> welcome to look at, based on the aforementioned article.
>
> Aaron
>
Greetings, deacon Marcus
~~~~~
HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting,
please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
=====
> On Thu, 4 Oct 2001, Deacon Marcus wrote:
> > Hi,
> >
> > > From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, October 04, 2001 2:35 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [half-off-topic] Java Compilers
> > >
> > >
> > > Hi,
> > >
> > > On Thu, 4 Oct 2001, Deacon Marcus wrote:
> > >
> > > > There would be two classes, CompileUnit and CompileContext.
> > > > First, you create a CompileContext, initialize it with
> working dir and
> > > > classpath, then you create CompileUnit, initialize it with
> > > CompileContext
> > > > and a .java file. Then, you can call .prepare() or .compile()
> > > to compile the
> > > > file, and .newInstance() to create an instance or .getClass()
> > > to get Class.
> > > > Or you could use Class.forName(), since in most cases
> CompileContext's
> > > > classpath would be active classpath.
> > > so you're talking about generating java source code, and
> compiling it on
> > > the fly?
> >
> > Exactly.
> > I'm coding it right now - looks like CompileContext is enough -
> I'll post
> > when I finish of course.
> >
> > > > I'm sure you see the similarity to .JSP now.
> > > if my interpretation is correct, yes (o:
> > >
> > > > While it may seem basic, having API for this wouldn't hurt.
> > > > Possible scenario:
> > > > Supponse, there's some kind of mail server with *extremely*
> complicated
> > > > rule-set in form of 200kb+ xml. Why not take it, convert it
> into .java
> > > > implementing some interface, convert it to java source with
> > > hundreds if not
> > > > more ifs and cases, and load it as compiled code.
> > > > What I need: since JDK 1.4b2, tools.jar just isn't what it used
> > > to be... so
> > > > I need some kind of 100% java java compiler. And, I have no
> > > idea where to
> > > > search for one. Of course, there's dozens, but it must be both
> > > stable and
> > > > compatible with JDK 1.1 - 1.4.
> > > Short of searching google, which I'm sure you're already
> doing I cant help
> > > you there. What I can suggest though, is for source code
> generation, a
> > > project called Jenesis (http://www.inxar.org) which provides
> a nice API
> > > based on the Java Language spec.
> >
> > Generating source is out of scope of this project.
> > I need it mainly for the complicated configs etc - no point in
> generating
> > structure out of xml which is then analyzed everytime when you
> can compile
> > it into bytecode. I'm sure it's possible to do xml-config to java-source
> > transformation in xsl, but I don't like it personally, so I'll
> leave it to
> > someone else.
> >
> > > cheers
> > > dim
> >
> > Greetings, deacon Marcus
> > ~~~~~
> > HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable
> JSP hosting,
> > please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW
> + 20mb mail)
> >
JJC.zip