Nabble - janino - user

AW: Re: [janino-dev] Maintained Janino Releases

2009-12-02T01:23:21Z

Hi all,

Thanks for all your effort to maintain the project. I think to most users it will be important that Janino lives on (me included). It would be best to "take over" the project on codehaus but if it is not possible, forking Janino is the only option left.

Cheers,

Robert

> -----Ursprüngliche Nachricht-----
> Von: Bradley Longstreth [mailto:longstrb@...]
> Gesendet: Mittwoch, 2. Dezember 2009 06:37
> An: user@...
> Cc: David L. Pinto
> Betreff: Re: [janino-user] Re: [janino-dev] Maintained Janino Releases
>
> Hello All:
>
> FWIW: I too am a user of janino and really need to see it live
> on...thanks for your efforts!
>
> Bradley
>
>
> ________________________________
>
> From: Matt Fowles <matt.fowles@...>
> To: dev@...
> Cc: Janino <user@...>; Arno Unkrig <arno@...>
> Sent: Tue, December 1, 2009 3:41:32 PM
> Subject: [janino-user] Re: [janino-dev] Maintained Janino Releases
>
> Mark~
>
> I completely agree with you, that is why I sent Arno (and the list) an
> email in February to see if he could be stirred up.
>
> http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf19117
> 0902052034p7cb828eagbde767ed605b62bd@...
>
>
> Then sent a follow up in June announcing the initial branch.
>
> http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf19117
> 0906051054s72c7698cn57f22ee0eab80122@...
>
>
> And instructed people on the initial branch to continue using Janino's
> Jira.
>
> http://code.google.com/p/janino-streambase/
>
>
> This is, in fact, a very paced effort on my part. Also, I should be
> extra clear, that if after some time, Arno does return, I will be happy
> to cede the project back to him. I also emailed him directly twice
> during the intervening time, as prior to December 2008, we had
> exchanged friendly personal emails.
>
> Matt
>
>
> On Tue, Dec 1, 2009 at 5:32 PM, Mark Proctor <mproctor@...>
> wrote:
>
>
> Matt Fowles wrote:
>
>
> All~
>
> Arno has been inaccessible for about a year now, and
> tickets in Janino's Jira grow older without update. I have been
> maintaining a google code project which fixes most of the issues in the
> current Janino environment. The number of issues fixed and the delta
> from janino trunk has grown to the point, where I would like some more
> permanent solution. I am somewhat loathe to fork Janino, but I do not
> readily see any alternatives. Does anyone have opinions or
> suggestions?
>
>
> I'd give a month for Arno to respond. Then submit your proposal
> to this list, twice, and wait 2 weeks to see if anyone objects. If no
> one objects I then think a fork is acceptable, as long as it's charter
> is to unwind if/when the original author comes back on the scene and
> merges things back in. Also make sure the fork communicates this
> correctly, so that people don't see it as an aggressive move, and that
> Arno is given the full credit for his work.
>
> Mark
>
>
>
> Matt
>
>
>
>
>
>
>
> -----------------------------------------------------------------
> ----
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Re: [janino-dev] Maintained Janino Releases

2009-12-01T21:36:35Z

Hello All:

FWIW: I too am a user of janino and really need to see it live on...thanks for your efforts!

Bradley

From: Matt Fowles <matt.fowles@...>
To: dev@...
Cc: Janino <user@...>; Arno Unkrig <arno@...>
Sent: Tue, December 1, 2009 3:41:32 PM
Subject: [janino-user] Re: [janino-dev] Maintained Janino Releases

Mark~

I completely agree with you, that is why I sent Arno (and the list) an email in February to see if he could be stirred up.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170902052034p7cb828eagbde767ed605b62bd@...

Then sent a follow up in June announcing the initial branch.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170906051054s72c7698cn57f22ee0eab80122@...

And instructed people on the initial branch to continue using Janino's Jira.

http://code.google.com/p/janino-streambase/

This is, in fact, a very paced effort on my part. Also, I should be extra clear, that if after some time, Arno does return, I will be happy to cede the project back to him. I also emailed him directly twice during the intervening time, as prior to December 2008, we had exchanged friendly personal emails.

Matt

On Tue, Dec 1, 2009 at 5:32 PM, Mark Proctor <mproctor@...> wrote:

Matt Fowles wrote:

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

I'd give a month for Arno to respond. Then submit your proposal to this list, twice, and wait 2 weeks to see if anyone objects. If no one objects I then think a fork is acceptable, as long as it's charter is to unwind if/when the original author comes back on the scene and merges things back in. Also make sure the fork communicates this correctly, so that people don't see it as an aggressive move, and that Arno is given the full credit for his work.

Mark

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maintained Janino Releases

2009-12-01T19:34:24Z

+1

Randy Wigginton wrote:

> Matt, please consider this another "vote from the field". Janino is incredibly useful, and one of my favorite tools. Thank you for keeping the spirit alive!
>
> On Dec 1, 2009, at 7:40 AM, Matt Fowles wrote:
>
>> All~
>>
>> Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?
>>
>> Matt
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maintained Janino Releases

2009-12-01T19:23:20Z

Matt, please consider this another "vote from the field". Janino is incredibly useful, and one of my favorite tools. Thank you for keeping the spirit alive!

On Dec 1, 2009, at 7:40 AM, Matt Fowles wrote:

> All~
>
> Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?
>
> Matt
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: [janino-dev] Maintained Janino Releases

2009-12-01T14:51:59Z

Matt Fowles wrote:

Mark~

I completely agree with you, that is why I sent Arno (and the list) an email in February to see if he could be stirred up.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170902052034p7cb828eagbde767ed605b62bd@...

Then sent a follow up in June announcing the initial branch.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170906051054s72c7698cn57f22ee0eab80122@...

And instructed people on the initial branch to continue using Janino's Jira.

http://code.google.com/p/janino-streambase/

This is, in fact, a very paced effort on my part. Also, I should be extra clear, that if after some time, Arno does return, I will be happy to cede the project back to him. I also emailed him directly twice during the intervening time, as prior to December 2008, we had exchanged friendly personal emails.

Give 2 weeks for anyone to object, send another email one week later, then I think you are good to go.

Mark

Matt

On Tue, Dec 1, 2009 at 5:32 PM, Mark Proctor <mproctor@...> wrote:

Matt Fowles wrote:

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

I'd give a month for Arno to respond. Then submit your proposal to this list, twice, and wait 2 weeks to see if anyone objects. If no one objects I then think a fork is acceptable, as long as it's charter is to unwind if/when the original author comes back on the scene and merges things back in. Also make sure the fork communicates this correctly, so that people don't see it as an aggressive move, and that Arno is given the full credit for his work.

Mark

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Re: [janino-dev] Maintained Janino Releases

2009-12-01T14:49:50Z

Mark,

If we give the notifications you describe and Arno doesn't respond,
can Matt be given administrative control over the Janino codehaus
project? It would be a shame to have to fork the project so that users
who go to the original site would get the obsolete version or submit
bug reports that nobody can respond to.

There is a subversion repository that will allow anyone who wants to
get access to earlier releases. We can increment the version number to
make it easy to retrieve the current version.

If Arno does return, he can take control back.

Matt has pretty much already given the notification you suggested, but
if it takes an additional month to give him control it would be well
worth it.

Thanks,
Hayden

On Dec 1, 2009, at 5:32 PM, Mark Proctor wrote:

> Matt Fowles wrote:
>> All~
>>
>> Arno has been inaccessible for about a year now, and tickets in
>> Janino's Jira grow older without update. I have been maintaining a
>> google code project which fixes most of the issues in the current
>> Janino environment. The number of issues fixed and the delta from
>> janino trunk has grown to the point, where I would like some more
>> permanent solution. I am somewhat loathe to fork Janino, but I do
>> not readily see any alternatives. Does anyone have opinions or
>> suggestions?
> I'd give a month for Arno to respond. Then submit your proposal to
> this list, twice, and wait 2 weeks to see if anyone objects. If no
> one objects I then think a fork is acceptable, as long as it's
> charter is to unwind if/when the original author comes back on the
> scene and merges things back in. Also make sure the fork
> communicates this correctly, so that people don't see it as an
> aggressive move, and that Arno is given the full credit for his work.
>
> Mark
>>
>> Matt
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: [janino-dev] Maintained Janino Releases

2009-12-01T14:41:32Z

Mark~

I completely agree with you, that is why I sent Arno (and the list) an email in February to see if he could be stirred up.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170902052034p7cb828eagbde767ed605b62bd@...

Then sent a follow up in June announcing the initial branch.

http://archive.codehaus.org/lists/org.codehaus.janino.user/msg/fbf191170906051054s72c7698cn57f22ee0eab80122@...

And instructed people on the initial branch to continue using Janino's Jira.

http://code.google.com/p/janino-streambase/

Matt

On Tue, Dec 1, 2009 at 5:32 PM, Mark Proctor <mproctor@...> wrote:

Matt Fowles wrote:

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

I'd give a month for Arno to respond. Then submit your proposal to this list, twice, and wait 2 weeks to see if anyone objects. If no one objects I then think a fork is acceptable, as long as it's charter is to unwind if/when the original author comes back on the scene and merges things back in. Also make sure the fork communicates this correctly, so that people don't see it as an aggressive move, and that Arno is given the full credit for his work.

Mark

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: [janino-dev] Maintained Janino Releases

2009-12-01T14:32:02Z

Matt Fowles wrote:
> All~
>
> Arno has been inaccessible for about a year now, and tickets in
> Janino's Jira grow older without update. I have been maintaining a
> google code project which fixes most of the issues in the current
> Janino environment. The number of issues fixed and the delta from
> janino trunk has grown to the point, where I would like some more
> permanent solution. I am somewhat loathe to fork Janino, but I do not
> readily see any alternatives. Does anyone have opinions or suggestions?
I'd give a month for Arno to respond. Then submit your proposal to this
list, twice, and wait 2 weeks to see if anyone objects. If no one
objects I then think a fork is acceptable, as long as it's charter is to
unwind if/when the original author comes back on the scene and merges
things back in. Also make sure the fork communicates this correctly, so
that people don't see it as an aggressive move, and that Arno is given
the full credit for his work.

Mark
>
> Matt
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maintained Janino Releases

2009-12-01T12:48:46Z

Another thank you from the field Matt.

We use Janino for some parsing where using the Eclipse JDT is overkill. Add me to the vote for either a change in control or a fork.

-Adam Malter

TradeCard Inc.

On Tue, Dec 1, 2009 at 2:17 PM, Matt Fowles <matt.fowles@...> wrote:

James~

Glad to hear someone else is using Janino. At your suggestion, I have opened a general ticket with the codehaus folks to see if they have a policy about such things.

http://jira.codehaus.org/browse/HAUS-1890

Thanks,
Matt

On Tue, Dec 1, 2009 at 11:07 AM, James House <jhouse@...> wrote:

Matt,

I've (silently) appreciated your efforts over the months to keep Janino rolling.

I think it would be great to somehow keep it rolling long-term. Avoiding a fork would be good, but if Arno continues to be unreachable, and therefore does not make any further changes to Janino, then a fork would be better than letting it die.

Have you contacted anyone at CodeHaus to see if they have a policy regarding projects who's owners have gone missing?

james

Matt Fowles wrote:

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maintained Janino Releases

2009-12-01T11:17:12Z

James~

Glad to hear someone else is using Janino. At your suggestion, I have opened a general ticket with the codehaus folks to see if they have a policy about such things.

http://jira.codehaus.org/browse/HAUS-1890

Thanks,

Matt

On Tue, Dec 1, 2009 at 11:07 AM, James House <jhouse@...> wrote:

Matt,

I've (silently) appreciated your efforts over the months to keep Janino rolling.

I think it would be great to somehow keep it rolling long-term. Avoiding a fork would be good, but if Arno continues to be unreachable, and therefore does not make any further changes to Janino, then a fork would be better than letting it die.

Have you contacted anyone at CodeHaus to see if they have a policy regarding projects who's owners have gone missing?

james

Matt Fowles wrote:

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Maintained Janino Releases

2009-12-01T08:07:13Z

Matt,

I've (silently) appreciated your efforts over the months to keep Janino
rolling.

I think it would be great to somehow keep it rolling long-term.
Avoiding a fork would be good, but if Arno continues to be unreachable,
and therefore does not make any further changes to Janino, then a fork
would be better than letting it die.

Have you contacted anyone at CodeHaus to see if they have a policy
regarding projects who's owners have gone missing?

james

Matt Fowles wrote:

> All~
>
> Arno has been inaccessible for about a year now, and tickets in
> Janino's Jira grow older without update. I have been maintaining a
> google code project which fixes most of the issues in the current
> Janino environment. The number of issues fixed and the delta from
> janino trunk has grown to the point, where I would like some more
> permanent solution. I am somewhat loathe to fork Janino, but I do not
> readily see any alternatives. Does anyone have opinions or suggestions?
>
> Matt
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Maintained Janino Releases

2009-12-01T07:40:55Z

All~

Arno has been inaccessible for about a year now, and tickets in Janino's Jira grow older without update. I have been maintaining a google code project which fixes most of the issues in the current Janino environment. The number of issues fixed and the delta from janino trunk has grown to the point, where I would like some more permanent solution. I am somewhat loathe to fork Janino, but I do not readily see any alternatives. Does anyone have opinions or suggestions?

Matt

Re: FW: Janino and Code Cache OutOfMemoryError

2009-10-27T07:19:59Z

Paul~

I am not entirely sure about your situation, but I would guess that this is from instances of the generated classes surviving longer then you expect. Every object in Java holds a reference to its Class and every Class holds an reference to its ClassLoader, so if your code instantiates the Class that you are generating, then the code objects and the ClassLoader will survive as long as that instance does.

If you are not instantiating the classes at all, I would examine the static and thread local variables that are referenced in your traces below to ensure that they are not squirreling away Class or ClassLoader references.

Matt

On Tue, Oct 27, 2009 at 5:14 AM, Paul Nolan <paul.nolan@...> wrote:

I should also add, when I look at what references org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, I get pages and pages of classes that reference it, including many static references to it from "system" classes. This does not make a lot of sense since the classes that would be required to compile the code passed in to the ClassBodyEvaluator are not that many. For example, here is a reference to the ByteArrayClassLoader:

Static reference from net.sf.cglib.core.ReflectUtils.defaultLoader (from class net.sf.cglib.core.ReflectUtils) :
--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

here is another:

Static reference from org.apache.commons.configuration.ConfigurationUtils.class$org$apache$commons$configuration$ConfigurationUtils (from class org.apache.commons.configuration.ConfigurationUtils) :
--> class org.apache.commons.configuration.ConfigurationUtils (84 bytes) (??:)
--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

thanks,

- Paul.

On Tue, Oct 27, 2009 at 9:07 AM, Paul Nolan <Paul.Nolan@...> wrote:

From: Paul Nolan [mailto:paul.nolan@...]
Sent: 27 October 2009 08:58
To: user@...
Subject: [janino-user] Janino and Code Cache OutOfMemoryError

Hi,

I have a ituation where I am running some code inside our home grown application server. This code uses Janino to generate code on the fly using the ClassBodyEvaluator and, to a lesser extend, the SimpleCompiler. This code is not executed in any way - we compile the code to "test" rules input by users into our system to make sure that the rules are correct.

First I should say that permGen space is *not* filling up, just the code cache. I am seeing a situation where the code cache is filling up. Now, my understanding of this is that the reason the code cache is filling up is due to some reference to the class compiled by ClassBodyEvaluator is still hanging around in the system. However, my confusion is this: If this is the case then surely the permGen space should alse fill up (or possibly it does so at a much smaller pace than the code cache since it stores meta data only?).

I have passed a custom class loader into the ClassBodyEvaluator to see if this solves the issue but it does not e.g.

            ClassBodyEvaluator cbe = new ClassBodyEvaluator();
            cbe.setParentClassLoader(RVClassLoaderFactory.getRVClassLoader());
            cbe.cook(code);

In my testing code, I nullify my custom class loader when I am finished with it but the code cache still grows and does not get garbage collected. Using JDK 6.

I have used jmap and jhat to try and see what is referencing my class, the following information is from a jmap dump:

      1. ClassLoader for my generated class: org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes) (note: not my custom classLoader I pass in above).

      2. In my investiagations using jmap, the finger consistently points at org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, even though I pass in a custom class loader above when I am generating the code.

Now, it is well possible that my understanding of how Janino uses classLoaders is limited or how classLoaders work, so if so apologies.

My general question is can someone enlighten me as to the best way to ensure that my code cache does not fill up? Is it as simple as calling Thread.currentThread().setContextClassLoader() ?

regards,

- Paul.

Re: FW: Janino and Code Cache OutOfMemoryError

2009-10-27T02:14:50Z

I should also add, when I look at what references org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, I get pages and pages of classes that reference it, including many static references to it from "system" classes. This does not make a lot of sense since the classes that would be required to compile the code passed in to the ClassBodyEvaluator are not that many. For example, here is a reference to the ByteArrayClassLoader:

Static reference from net.sf.cglib.core.ReflectUtils.defaultLoader (from class net.sf.cglib.core.ReflectUtils) :

--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

here is another:

Static reference from org.apache.commons.configuration.ConfigurationUtils.class$org$apache$commons$configuration$ConfigurationUtils (from class org.apache.commons.configuration.ConfigurationUtils) :

--> class org.apache.commons.configuration.ConfigurationUtils (84 bytes) (??:)
--> java.net.URLClassLoader@0x18030720 (63 bytes) (field classes:)
--> java.util.Vector@0x18079b60 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x191ff2a8 (40968 bytes) (Element 769 of [Ljava.lang.Object;@0x191ff2a8:)
--> class <mycompany>.cuf.datasource.portal.PortalDataSource (84 bytes) (static field _connectionManager:)
--> <mycompany>.jaf.services.database.ConnectionManagerBase@0x18030090 (184 bytes) (field _checkerThread:)
--> java.lang.Thread@0x18ac30d8 (104 bytes) (field group:)
--> java.lang.ThreadGroup@0x18030030 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x1a8024a0 (40 bytes) (Element 0 of [Ljava.lang.ThreadGroup;@0x1a8024a0:)
--> java.lang.ThreadGroup@0x180798f8 (43 bytes) (field threads:)
--> [Ljava.lang.Thread;@0x1b176678 (40 bytes) (Element 2 of [Ljava.lang.Thread;@0x1b176678:)
--> java.lang.Thread@0x1a92b240 (104 bytes) (field threadLocals:)
--> java.lang.ThreadLocal$ThreadLocalMap@0x1ab3b138 (20 bytes) (field table:)
--> [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68 (264 bytes) (Element 12 of [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry;@0x1add1f68:)
--> java.lang.ThreadLocal$ThreadLocalMap$Entry@0x1af03218 (28 bytes) (field value:)
--> com.<mycompany>.ro.plugin.rules.RuleValidation$CommonBody@0x1af031c8 (16 bytes) (field cbe:)
--> org.codehaus.janino.ClassBodyEvaluator@0x1af031e8 (48 bytes) (field result:)
--> org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes)

thanks,

- Paul.

On Tue, Oct 27, 2009 at 9:07 AM, Paul Nolan <Paul.Nolan@...> wrote:

From: Paul Nolan [mailto:paul.nolan@...]
Sent: 27 October 2009 08:58
To: user@...
Subject: [janino-user] Janino and Code Cache OutOfMemoryError

Hi,

I have a ituation where I am running some code inside our home grown application server. This code uses Janino to generate code on the fly using the ClassBodyEvaluator and, to a lesser extend, the SimpleCompiler. This code is not executed in any way - we compile the code to "test" rules input by users into our system to make sure that the rules are correct.

First I should say that permGen space is *not* filling up, just the code cache. I am seeing a situation where the code cache is filling up. Now, my understanding of this is that the reason the code cache is filling up is due to some reference to the class compiled by ClassBodyEvaluator is still hanging around in the system. However, my confusion is this: If this is the case then surely the permGen space should alse fill up (or possibly it does so at a much smaller pace than the code cache since it stores meta data only?).

I have passed a custom class loader into the ClassBodyEvaluator to see if this solves the issue but it does not e.g.

            ClassBodyEvaluator cbe = new ClassBodyEvaluator();
            cbe.setParentClassLoader(RVClassLoaderFactory.getRVClassLoader());
            cbe.cook(code);

In my testing code, I nullify my custom class loader when I am finished with it but the code cache still grows and does not get garbage collected. Using JDK 6.

I have used jmap and jhat to try and see what is referencing my class, the following information is from a jmap dump:

      1. ClassLoader for my generated class: org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes) (note: not my custom classLoader I pass in above).

      2. In my investiagations using jmap, the finger consistently points at org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, even though I pass in a custom class loader above when I am generating the code.

Now, it is well possible that my understanding of how Janino uses classLoaders is limited or how classLoaders work, so if so apologies.

My general question is can someone enlighten me as to the best way to ensure that my code cache does not fill up? Is it as simple as calling Thread.currentThread().setContextClassLoader() ?

regards,

- Paul.

Janino and Code Cache OutOfMemoryError

2009-10-27T01:58:17Z

Hi,

I have a ituation where I am running some code inside our home grown application server. This code uses Janino to generate code on the fly using the ClassBodyEvaluator and, to a lesser extend, the SimpleCompiler. This code is not executed in any way - we compile the code to "test" rules input by users into our system to make sure that the rules are correct.

First I should say that permGen space is *not* filling up, just the code cache. I am seeing a situation where the code cache is filling up. Now, my understanding of this is that the reason the code cache is filling up is due to some reference to the class compiled by ClassBodyEvaluator is still hanging around in the system. However, my confusion is this: If this is the case then surely the permGen space should alse fill up (or possibly it does so at a much smaller pace than the code cache since it stores meta data only?).

I have passed a custom class loader into the ClassBodyEvaluator to see if this solves the issue but it does not e.g.

            ClassBodyEvaluator cbe = new ClassBodyEvaluator();
            cbe.setParentClassLoader(RVClassLoaderFactory.getRVClassLoader());
            cbe.cook(code);

In my testing code, I nullify my custom class loader when I am finished with it but the code cache still grows and does not get garbage collected. Using JDK 6.

I have used jmap and jhat to try and see what is referencing my class, the following information is from a jmap dump:

      1. ClassLoader for my generated class: org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0 (54 bytes) (note: not my custom classLoader I pass in above).

      2. In my investiagations using jmap, the finger consistently points at org.codehaus.janino.ByteArrayClassLoader@0x1af0f9f0, even though I pass in a custom class loader above when I am generating the code.

Now, it is well possible that my understanding of how Janino uses classLoaders is limited or how classLoaders work, so if so apologies.

My general question is can someone enlighten me as to the best way to ensure that my code cache does not fill up? Is it as simple as calling Thread.currentThread().setContextClassLoader() ?

regards,

- Paul.

Re: Java varargs Compilation problem

2009-10-27T01:44:29Z

Thanks Matt, I was mistaken - this never compiled, hence the confusion.

best,

- Paul.

On Mon, Oct 26, 2009 at 3:07 PM, Matt Fowles <matt.fowles@...> wrote:

Paul~

Not sure if Janino used to support var-args or not. If it used to, then this is likely a regression. Regardless, you can work around the problem by generating code that directly calls the String[] variant.

Matt

On Fri, Oct 23, 2009 at 5:52 PM, Paul Nolan <paul.nolan@...> wrote:

Weird one here guys,

Using JDK:

java version "1.6.0_16"

Java(TM) SE Runtime Environment (build 1.6.0_16-b01)

Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

To the problem:

I am using janino-2.5.0 and I am noticing that the ClassBodyEvaluator is not compiling Java varargs anymore J It definitely compiled under JDK 5 and I think it did previously under JDK 6 but of course I know that makes no sense.

If I have a function:

public static boolean inListStripLeadingZeros(String search, String ... string) { // note var args at end

The following code is passed to ClassBodyEvaluator (along with more code):

if (MyFunctions.inListStripLeadingZeros(record.tariff_Class,"527", "777", "3027", "619", "869", "3169", "628", "878", "3128", "567", "817", "3067", "502", "752", "3002", "503", "504", "505", "506", "605", "564", "565", "526", "528", "533", "753", "754", "755", "756", "855", "814", "815", "778", "3003", "3004", "3005", "3006", "3105", "3064", "3065", "675", "557", "521", "597", "684", "685", "501", "564", "565", "925", "807", "771", "934", "935", "751", "814", "815")) {

return true;

}

This is the error I am now getting with Janino 2.5.0 and JDK 1.6:

No applicable constructor/method found for actual parameters "java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String"; candidates are: "boolean MyFunctions.inListStripLeadingZeros(java.lang.String, java.lang.String[])"

Has this been fixed in later version? I scanned the changelogs but could not find it.

Thanks.

Re: Java varargs Compilation problem

2009-10-26T08:07:41Z

Paul~

Not sure if Janino used to support var-args or not. If it used to, then this is likely a regression. Regardless, you can work around the problem by generating code that directly calls the String[] variant.

Matt

On Fri, Oct 23, 2009 at 5:52 PM, Paul Nolan <paul.nolan@...> wrote:

Weird one here guys,

Using JDK:

java version "1.6.0_16"

Java(TM) SE Runtime Environment (build 1.6.0_16-b01)

Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

To the problem:

I am using janino-2.5.0 and I am noticing that the ClassBodyEvaluator is not compiling Java varargs anymore J It definitely compiled under JDK 5 and I think it did previously under JDK 6 but of course I know that makes no sense.

If I have a function:

public static boolean inListStripLeadingZeros(String search, String ... string) { // note var args at end

The following code is passed to ClassBodyEvaluator (along with more code):

if (MyFunctions.inListStripLeadingZeros(record.tariff_Class,"527", "777", "3027", "619", "869", "3169", "628", "878", "3128", "567", "817", "3067", "502", "752", "3002", "503", "504", "505", "506", "605", "564", "565", "526", "528", "533", "753", "754", "755", "756", "855", "814", "815", "778", "3003", "3004", "3005", "3006", "3105", "3064", "3065", "675", "557", "521", "597", "684", "685", "501", "564", "565", "925", "807", "771", "934", "935", "751", "814", "815")) {

return true;

}

This is the error I am now getting with Janino 2.5.0 and JDK 1.6:

No applicable constructor/method found for actual parameters "java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String"; candidates are: "boolean MyFunctions.inListStripLeadingZeros(java.lang.String, java.lang.String[])"

Has this been fixed in later version? I scanned the changelogs but could not find it.

Thanks.

Java varargs Compilation problem

2009-10-23T14:52:01Z

Weird one here guys,

Using JDK:

java version "1.6.0_16"

Java(TM) SE Runtime Environment (build 1.6.0_16-b01)

Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)

To the problem:

I am using janino-2.5.0 and I am noticing that the ClassBodyEvaluator is not compiling Java varargs anymore J It definitely compiled under JDK 5 and I think it did previously under JDK 6 but of course I know that makes no sense.

If I have a function:

public static boolean inListStripLeadingZeros(String search, String ... string) { // note var args at end

The following code is passed to ClassBodyEvaluator (along with more code):

if (MyFunctions.inListStripLeadingZeros(record.tariff_Class,"527", "777", "3027", "619", "869", "3169", "628", "878", "3128", "567", "817", "3067", "502", "752", "3002", "503", "504", "505", "506", "605", "564", "565", "526", "528", "533", "753", "754", "755", "756", "855", "814", "815", "778", "3003", "3004", "3005", "3006", "3105", "3064", "3065", "675", "557", "521", "597", "684", "685", "501", "564", "565", "925", "807", "771", "934", "935", "751", "814", "815")) {

return true;

}

This is the error I am now getting with Janino 2.5.0 and JDK 1.6:

No applicable constructor/method found for actual parameters "java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String"; candidates are: "boolean MyFunctions.inListStripLeadingZeros(java.lang.String, java.lang.String[])"

Has this been fixed in later version? I scanned the changelogs but could not find it.

Thanks.

Re: Ignore Annotations

2009-09-25T10:27:49Z

Adam~

Hacking the scanner is probably the best bet. If you are feeling industrious, you could push the annotations into the parsed AST and then ignore them there instead. That would allow people to recover the annotations when pretty printing the AST and allow later developers to leverage your work.

I would also suggest that you base your work off of

http://code.google.com/p/janino-streambase/

which has a bunch of bug fixes that yet to be pushed up stream. Arno has been MIA for about half a year now.

Matt

On Fri, Sep 25, 2009 at 12:55 PM, Adam Malter <amalter@...> wrote:

Hi all,

I'm attempting to use Janino for java source parsing. We have a
project with a number of GWT modules and I'd like to run some
transformations on them before dropping them to the GWT compiler. My
first pass has been with the Eclipse JDT. I've got that running, but
it's huge and cumbersome.

With Janino, the show stopper right now is our sources are marked up
with annotations. For the purpose of the transformations I do not need
to parse these annotations. I looked in Scanner.java and it looks like
I could probably hack out a way to have Janino ignore the annotations,
but I wanted to see if there was a better way, or maybe even some
implementation sitting around that already did this.

Otherwise, what an awesome project, compile, transform, evaluate in
such a small package. Very nice and very cool!

-Adam Malter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Ignore Annotations

2009-09-25T09:55:22Z

Hi all,

I'm attempting to use Janino for java source parsing. We have a
project with a number of GWT modules and I'd like to run some
transformations on them before dropping them to the GWT compiler. My
first pass has been with the Eclipse JDT. I've got that running, but
it's huge and cumbersome.

With Janino, the show stopper right now is our sources are marked up
with annotations. For the purpose of the transformations I do not need
to parse these annotations. I looked in Scanner.java and it looks like
I could probably hack out a way to have Janino ignore the annotations,
but I wanted to see if there was a better way, or maybe even some
implementation sitting around that already did this.

Otherwise, what an awesome project, compile, transform, evaluate in
such a small package. Very nice and very cool!

-Adam Malter

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Dependency injection - Cannot determine simple type name

2009-08-05T08:13:22Z

Is Class2 an existing already loaded class or is it a class you are
compiling at the came time?

If it is an existing class make sure you pass a ClassLoader that can
resolve it to the compiler.

Also you should try using a fully qualified name in Class1, so refer
to is as "com.package.Class2" or what ever your package is for Class2.

Matt

On Wed, Aug 5, 2009 at 11:06 AM,
shikarishambu<shikarishambu70@...> wrote:

>
> I have a class that instantiates and calls a function on another class. When
> I try to invoke function on the first class I get
>
> ERROR:05/08/09 09:45:51:Janino compilation failure:
> File Class1, Line 29, Column 35: Cannot determine simple type name "Class2"
>
> How do I make janino aware of the dependencies. I have tried putting package
> <packagename>; declaration on top these files but that does not seem to
> help.
>
> TIA
> --
> View this message in context: http://www.nabble.com/Dependency-injection---Cannot-determine-simple-type-name-%3Cclassname%3E-tp24829676p24829676.html
> Sent from the janino - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Dependency injection - Cannot determine simple type name

2009-08-05T08:06:59Z

I have a class that instantiates and calls a function on another class. When I try to invoke function on the first class I get

ERROR:05/08/09 09:45:51:Janino compilation failure:
File Class1, Line 29, Column 35: Cannot determine simple type name "Class2"

How do I make janino aware of the dependencies. I have tried putting package <packagename>; declaration on top these files but that does not seem to help.

TIA

Bug Fixes and Mercurial Mirroring

2009-06-05T10:54:06Z

All~

I have started a mercurial mirror of Janino's SVN on google code. This mirror provides public access to StreamBase Systems's bug fixes that have yet to be incorporated upstream. The fixed bugs are:

I will be making a pass through the open tickets in Jira and pulling any other fixes that I can find into this mirror. This project is not meant to be a fork of Janino and will just stage changes until they are incorporated into Janino, unless Arno says otherwise.

Enjoy,
Matt

Small Nudge

2009-02-05T20:34:35Z

Arno~

I was poking around on the main page for the Janino website and noticed the limitations section. In particular

Local variable information information for debugging is not yet implemented (i.e. "-g:vars" is ignored)

This is fixed by the patch in http://jira.codehaus.org/browse/JANINO-127

Methods that compile to more than 32 KB of bytecode cannot be compiled (other Java^TM compilers support up to 64 KB per method)

Was already fixed by http://jira.codehaus.org/browse/JANINO-118

Also, I submitted patches for

http://jira.codehaus.org/browse/JANINO-126
http://jira.codehaus.org/browse/JANINO-129
http://jira.codehaus.org/browse/JANINO-130

which I would like to see brought upstream if possible.

Thanks,
Matt

Re: StackOverflow

2009-01-20T23:11:02Z

That is exactly what I thought the problem would be. I just didn't think it would fail so quickly...Anyway, thank you for the response.

Best Regards,

Bradley

From: Matt Fowles <matt.fowles@...>
To: user@...
Sent: Monday, January 19, 2009 2:56:30 PM
Subject: Re: [janino-user] StackOverflow

Bradley~

Janino uses a hand rolled recursive descent parser. What you are see is a natural consequence of that and cannot easily be fixed. The work around is to generate code like:

static Object getExpressionValue() {
int foo = SomeFunc(value, value, value, value);
foo += SumFunction(value, value, value, value);
foo += SumFunction(value, value, value, value);
...

}

Matt

On Fri, Jan 16, 2009 at 12:54 PM, Bradley Longstreth <longstrb@...> wrote:

Hello All:

I have a situation whereby we are generating dynamic classes on the fly using SimpleCompiler. Inside the class, we are reading, what could be very large expressions...Example:

class Foo {

static Object getExpressionValue() {
    SomeFunc(value, value, value, value) + SumFunction(value, value, value, value) + ....

}

}

This is a simple class demonstrating that I am generating a dynamic infix expression on the fly. As some point, when the expression gets large, I receive a stack overflow from the SimpleCompiler. In fact, I have seen where it will be okay...then on the next code generation it will fail. Now, when I say large, I mean about 180+ of the pattern SomeFunc(value,value,value,value))....Anyway, I have attached a partial stack trace to show the problem. Please let me know if there are any know issues or if I simply just need to break the expression up into smaller pieces. Also, I am not sure if the has to do with the 32k byte code generation. If so, I assume I will have to do something different with the dynamic expression generation...Any suggestions would be appreciated.

Best Regards,

Bradley

java.lang.StackOverflowError
        at org.codehaus.janino.Parser.peekOperator(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)

Re: StackOverflow

2009-01-19T14:26:49Z

Another workaround is that you can give yourself a larger stack size with the -XssN argument (n is the stack size). But that's a somewhat dangerous solution because a larger expression will require a larger stack, so you may not be able to be sure your stack size is large enough.

Matt's suggestion is safer.

Hayden

On Jan 19, 2009, at 4:56 PM, Matt Fowles wrote:

Bradley~

Janino uses a hand rolled recursive descent parser. What you are see is a natural consequence of that and cannot easily be fixed. The work around is to generate code like:

static Object getExpressionValue() {
    int foo = SomeFunc(value, value, value, value);
foo += SumFunction(value, value, value, value);
foo += SumFunction(value, value, value, value);
    ...
}

Matt

On Fri, Jan 16, 2009 at 12:54 PM, Bradley Longstreth <longstrb@...> wrote:

Hello All:

I have a situation whereby we are generating dynamic classes on the fly using SimpleCompiler. Inside the class, we are reading, what could be very large expressions...Example:

class Foo {

static Object getExpressionValue() {
    SomeFunc(value, value, value, value) + SumFunction(value, value, value, value) + ....

}

}

This is a simple class demonstrating that I am generating a dynamic infix expression on the fly. As some point, when the expression gets large, I receive a stack overflow from the SimpleCompiler. In fact, I have seen where it will be okay...then on the next code generation it will fail. Now, when I say large, I mean about 180+ of the pattern SomeFunc(value,value,value,value))....Anyway, I have attached a partial stack trace to show the problem. Please let me know if there are any know issues or if I simply just need to break the expression up into smaller pieces. Also, I am not sure if the has to do with the 32k byte code generation. If so, I assume I will have to do something different with the dynamic expression generation...Any suggestions would be appreciated.

Best Regards,

Bradley

java.lang.StackOverflowError
        at org.codehaus.janino.Parser.peekOperator(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)

Re: StackOverflow

2009-01-19T13:56:30Z

Bradley~

Janino uses a hand rolled recursive descent parser. What you are see is a natural consequence of that and cannot easily be fixed. The work around is to generate code like:

static Object getExpressionValue() {
int foo = SomeFunc(value, value, value, value);
foo += SumFunction(value, value, value, value);
foo += SumFunction(value, value, value, value);
...

}

Matt

On Fri, Jan 16, 2009 at 12:54 PM, Bradley Longstreth <longstrb@...> wrote:

Hello All:

I have a situation whereby we are generating dynamic classes on the fly using SimpleCompiler. Inside the class, we are reading, what could be very large expressions...Example:

class Foo {

static Object getExpressionValue() {
    SomeFunc(value, value, value, value) + SumFunction(value, value, value, value) + ....

}

}

This is a simple class demonstrating that I am generating a dynamic infix expression on the fly. As some point, when the expression gets large, I receive a stack overflow from the SimpleCompiler. In fact, I have seen where it will be okay...then on the next code generation it will fail. Now, when I say large, I mean about 180+ of the pattern SomeFunc(value,value,value,value))....Anyway, I have attached a partial stack trace to show the problem. Please let me know if there are any know issues or if I simply just need to break the expression up into smaller pieces. Also, I am not sure if the has to do with the 32k byte code generation. If so, I assume I will have to do something different with the dynamic expression generation...Any suggestions would be appreciated.

Best Regards,

Bradley

java.lang.StackOverflowError
        at org.codehaus.janino.Parser.peekOperator(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)

StackOverflow

2009-01-16T09:54:31Z

Hello All:

I have a situation whereby we are generating dynamic classes on the fly using SimpleCompiler. Inside the class, we are reading, what could be very large expressions...Example:

class Foo {

static Object getExpressionValue() {
SomeFunc(value, value, value, value) + SumFunction(value, value, value, value) + ....

}

}

This is a simple class demonstrating that I am generating a dynamic infix expression on the fly. As some point, when the expression gets large, I receive a stack overflow from the SimpleCompiler. In fact, I have seen where it will be okay...then on the next code generation it will fail. Now, when I say large, I mean about 180+ of the pattern SomeFunc(value,value,value,value))....Anyway, I have attached a partial stack trace to show the problem. Please let me know if there are any know issues or if I simply just need to break the expression up into smaller pieces. Also, I am not sure if the has to do with the 32k byte code generation. If so, I assume I will have to do something different with the dynamic expression generation...Any suggestions would be appreciated.

Best Regards,

Bradley

java.lang.StackOverflowError
        at org.codehaus.janino.Parser.peekOperator(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)
        at org.codehaus.janino.Parser.parseUnaryExpression(Parser.java)
        at org.codehaus.janino.Parser.parseMultiplicativeExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAdditiveExpression(Parser.java)
        at org.codehaus.janino.Parser.parseShiftExpression(Parser.java)
        at org.codehaus.janino.Parser.parseRelationalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseEqualityExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseInclusiveOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalAndExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalOrExpression(Parser.java)
        at org.codehaus.janino.Parser.parseConditionalExpression(Parser.java)
        at org.codehaus.janino.Parser.parseAssignmentExpression(Parser.java)
        at org.codehaus.janino.Parser.parseExpression(Parser.java)
        at org.codehaus.janino.Parser.parseArgumentList(Parser.java)
        at org.codehaus.janino.Parser.parseArguments(Parser.java)
        at org.codehaus.janino.Parser.parsePrimary(Parser.java)

cros reference between classes in diferent packages

2008-11-18T14:09:35Z

hy all.
i´m needing to compile two clases located in diferent packages
and each one refer the other by one attribute (i show am example bellow)

package a;

public class A{
public b.B bbb;
}

package b;

public class B{
public a.A aaa;
}

plese, anyone has any idea of how can i do this classes compilation using janino?

Problem with SimpleCompiler in compiling into existing class loader

2008-11-18T01:42:09Z

Hello,

I'm trying to load dynamic classes into the default Classloader.

For this I'm using Janino in the following manner :

{code}
SimpleCompiler simpleCompiler = new SimpleCompiler();
ClassLoader cl = this.getClass().getClassLoader();
simpleCompiler.setParentClassLoader(cl);
simpleCompiler.cookFile(new
File("/tmp/XX/dynamicSrc/com/XX/common/dataModel/facts/dynamic/XX.java"));

// Attempt #1 - Exception.
cl.loadClass("com.XX.common.dataModel.facts.dynamic.XX");

// Attempt #2 - Exception
Object o = Class.forName("com.XX.common.dataModel.facts.dynamic.XX");
{code}

Could you please suggest what I'm doing wrong ?
Or perhaps a different solution that would allow to me to compile a
.class file from within my application. I would then copy the .class
files to a location where the Tomcat WebappClassLoader could find
them...

Help is very much appreciated.

Thank you,
Maxim.

--
Cheers,
Maxim Veksler

"Free as in Freedom" - Do u GNU ?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Bytecode Generation

2008-06-18T14:10:45Z

Arno~

I definitely find the visitor pattern to be a mixed blessing. It has
a lot of advantages, but it does introduce a great deal of complexity
into code. I suppose all things have trade offs...

Matt

On Wed, Jun 18, 2008 at 5:00 PM, Arno Unkrig <arno@...> wrote:

> Matt Fowles schrieb:
>>
>> Arno~
>>
>> On Sat, Jun 14, 2008 at 5:54 PM, Arno Unkrig <arno@...> wrote:
>>>
>>> Matt Fowles schrieb:
>>>>
>>>> All~
>>>>
>>> ...
>>>>
>>>> went very smoothly. I was a little surprised to discover that Janino
>>>> requires its AST to actually be a tree. Our internal stuff allows for
>>>> sub-expression reuse with in the tree. But emitting a tree was a
>>>
>>> That's because compile-time status information is stored in the AST.
>>> Surely
>>> a design flaw, but really difficult to resolve without splitting up all
>>> the
>>> AST classes and ending up with twice the number of classes, and a lot of
>>> glue code.
>>
>> Yes, I figured that out. I agree with you that it might be a flaw,
>> but the flip side is the extra classes you mentioned. I am not sure
>> either what the "correct" design is. Although I have noticed that
>> compilers tend to be complicated beasts...
>>
>> Matt
>
> Yep, exactly. And one big design goal of JANINO is simplicity. I hate
> structures being duplicated...
>
> BTW, this issue is a bit of a shame: In ancient versions, the AST nodes all
> had "compile()" and "getType()" methods. Then, one day, I decided to switch
> to the VISITOR pattern to get the compilation logic out of the AST classes.
> When I was finished, I couldn't find a reasonable way to get the compile
> time state information out of the AST nodes. In retrospect, maybe I'd better
> left ALL the compilation logic inside the AST.
>
> But the VISITOR pattern functions prettily for UnparseVisitor and stuff, so
> the refactoring was not a complete mess.
>
>
> CU
>
> Arno
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Bytecode Generation

2008-06-18T14:00:58Z

Matt Fowles schrieb:

> Arno~
>
> On Sat, Jun 14, 2008 at 5:54 PM, Arno Unkrig <arno@...> wrote:
>> Matt Fowles schrieb:
>>> All~
>>>
>> ...
>>> went very smoothly. I was a little surprised to discover that Janino
>>> requires its AST to actually be a tree. Our internal stuff allows for
>>> sub-expression reuse with in the tree. But emitting a tree was a
>> That's because compile-time status information is stored in the AST. Surely
>> a design flaw, but really difficult to resolve without splitting up all the
>> AST classes and ending up with twice the number of classes, and a lot of
>> glue code.
>
> Yes, I figured that out. I agree with you that it might be a flaw,
> but the flip side is the extra classes you mentioned. I am not sure
> either what the "correct" design is. Although I have noticed that
> compilers tend to be complicated beasts...
>
> Matt

Yep, exactly. And one big design goal of JANINO is simplicity. I hate
structures being duplicated...

BTW, this issue is a bit of a shame: In ancient versions, the AST nodes
all had "compile()" and "getType()" methods. Then, one day, I decided to
switch to the VISITOR pattern to get the compilation logic out of the
AST classes. When I was finished, I couldn't find a reasonable way to
get the compile time state information out of the AST nodes. In
retrospect, maybe I'd better left ALL the compilation logic inside the AST.

But the VISITOR pattern functions prettily for UnparseVisitor and stuff,
so the refactoring was not a complete mess.

CU

Arno

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Bytecode Generation

2008-06-14T15:03:21Z

Arno~

On Sat, Jun 14, 2008 at 5:54 PM, Arno Unkrig <arno@...> wrote:

> Matt Fowles schrieb:
>>
>> All~
>>
> ...
>>
>> went very smoothly. I was a little surprised to discover that Janino
>> requires its AST to actually be a tree. Our internal stuff allows for
>> sub-expression reuse with in the tree. But emitting a tree was a
>
> That's because compile-time status information is stored in the AST. Surely
> a design flaw, but really difficult to resolve without splitting up all the
> AST classes and ending up with twice the number of classes, and a lot of
> glue code.

Yes, I figured that out. I agree with you that it might be a flaw,
but the flip side is the extra classes you mentioned. I am not sure
either what the "correct" design is. Although I have noticed that
compilers tend to be complicated beasts...

Matt

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: What is Java.EnclosingScopeOfTypeDeclaration for?

2008-06-14T14:57:57Z

Matt Fowles schrieb:
> All~
>
> What is the class Java.EnclosingScopeOfTypeDeclaration use for?
>
> The comment just says that is does something lazily, but I don't see
> why that laziness is needed or desirable.
>
> Matt

To be honest... I can't really remember. But if you replace all
instantiations of this class with "Type()", you end up with endless
loops while nested types are unrolled.

Need to do some more research.

CU

Arno

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re: Bytecode Generation

2008-06-14T14:54:20Z

Matt Fowles schrieb:
> All~
>
...
> went very smoothly. I was a little surprised to discover that Janino
> requires its AST to actually be a tree. Our internal stuff allows for
> sub-expression reuse with in the tree. But emitting a tree was a

That's because compile-time status information is stored in the AST.
Surely a design flaw, but really difficult to resolve without splitting
up all the AST classes and ending up with twice the number of classes,
and a lot of glue code.

...
> All told, Janino has been very reliable and easy to target, has a
> license amenable to use in a commercial project, and the internal code
> is straight forward enough to extend and fix bugs in without
> difficulty.

Thank you!

CU

Arno

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email