[Laszlo-dev] For Review: Change 20080904-hqm-J Summary: call flex compiler classes directly from jar file

Henry Minsky hminsky at laszlosystems.com
Fri Sep 5 07:46:27 PDT 2008


So is there a portable way to exec a new Java process? I *think* David's
objection was thatthe exec we were doing originally was not portable across
all possible java operating system environments.
Is there a vanilla way in Java to say "exec a new Java process with calling
this
class/method to start, or passing a class which has a main() method?



On Fri, Sep 5, 2008 at 10:05 AM, Donald Anderson <dda at ddanderson.com> wrote:

> I would tend to agree.  For one thing, it looks like we'd need to configure
> the java vm fortomcat with an extra amount (surely it can't be
> 300K??) just in case they use the SWF9 compiler.
> If you happen to do development on a machine with 1G or less of physical
> memory,
> you could have a lot of thrashing.
>
> On Sep 5, 2008, at 4:03 AM, P T Withington wrote:
>
> At the very least.  I am still campaigning for it to be called in a
> separate process because:
>
> + The server is a long-running process that has to maintain state
>
> + The compiler is a task that does not maintain state from one invocation
> to the next
>
> Hence the compiler is an excellent candidate for 'unix GC', i.e., use a
> process to reclaim all resources when the task is done.  That ensures the
> compiler will not jeopardize the server's uptime.
>
> There is the issue of ensuring that the compiler process must run
> 'headless' so that it does not throw up a bogus window/task-bar entry (which
> is the default thing for a java process to do).
>
> On 2008-09-04, at 20:44EDT, Henry Minsky wrote:
>
> Maybe I should have the callJavaCompileCommand method call the flex
> compilerin
>
> a new thread??
>
>
>
>
> On Thu, Sep 4, 2008 at 8:43 PM, Henry Minsky <hminsky at laszlosystems.com
> >wrote:
>
>
>
>
> 2)
>
> +        exitval = flex2.compiler.util.ThreadLocalToolkit.errorCount();
>
> Couldn't find any doc for ThreadLocalToolkit.  Are the errors additive,
>
> or will they be reset to 0 on each call into the compiler?  (i.e. I'm
>
> worried about an error being 'sticky' to the next compile - I guess
>
> it would only result in a stray FAIL println to the error console).
>
>
>
> The ThreadLocalToolkit class has a flex Logger object, which is stored
>
> within a ThreadLocal
>
> object, which is a Java thing that creates local vars which are unique to a
>
> thread.  The Logger object
>
> holds the error count. So as long as each compile is done in a new thread,
>
> the error count
>
> will get reset. Now, the question is whether each compile actually does
>
> happen in a new thread. I
>
> bet Tomcat has some kind of a thread pool, so I wonder if this is going to
>
> cause confusion
>
> at some point.
>
>
>
>
>
>
>
>
>
> --
>
> Henry Minsky
>
> Software Architect
>
> hminsky at laszlosystems.com
>
>
>
>
> --
>
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
>
> voice: 617-547-7881
> email: dda at ddanderson.com
> www: http://www.ddanderson.com
>
>
>
>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20080905/d4bb5ba6/attachment.html


More information about the Laszlo-dev mailing list