<div dir="ltr">So is there a portable way to exec a new Java process? I *think* David's objection was that<div>the exec we were doing originally was not portable across all possible java operating system environments. </div>
<div>Is there a vanilla way in Java to say "exec a new Java process with calling this</div><div>class/method to start, or passing a class which has a main() method?</div><div><br></div><div><br><br><div class="gmail_quote">
On Fri, Sep 5, 2008 at 10:05 AM, Donald Anderson <span dir="ltr"><<a href="mailto:dda@ddanderson.com">dda@ddanderson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">I would tend to agree. For one thing, it looks like we'd need to configure the java vm for<div>tomcat with an extra amount (surely it can't be 300K??) just in case they use the SWF9 compiler.</div>
<div>If you happen to do development on a machine with 1G or less of physical memory,</div><div>you could have a lot of thrashing.</div><div><br></div><div><div><div><div><div><div></div><div class="Wj3C7c"><div><div>On Sep 5, 2008, at 4:03 AM, P T Withington wrote:</div>
<br><blockquote type="cite"><div>At the very least. I am still campaigning for it to be called in a separate process because:<br><br>+ The server is a long-running process that has to maintain state<br><br>+ The compiler is a task that does not maintain state from one invocation to the next<br>
<br>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.<br><br>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).<br>
<br>On 2008-09-04, at 20:44EDT, Henry Minsky wrote:<br><br><blockquote type="cite">Maybe I should have the callJavaCompileCommand method call the flex compilerin<br></blockquote><blockquote type="cite">a new thread??<br></blockquote>
<blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Thu, Sep 4, 2008 at 8:43 PM, Henry Minsky <<a href="mailto:hminsky@laszlosystems.com" target="_blank">hminsky@laszlosystems.com</a>>wrote:<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">2)<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+ exitval = flex2.compiler.util.ThreadLocalToolkit.errorCount();<br>
</blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Couldn't find any doc for ThreadLocalToolkit. Are the errors additive,<br></blockquote></blockquote></blockquote>
<blockquote type="cite"><blockquote type="cite"><blockquote type="cite">or will they be reset to 0 on each call into the compiler? (i.e. I'm<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
<blockquote type="cite">worried about an error being 'sticky' to the next compile - I guess<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">it would only result in a stray FAIL println to the error console).<br>
</blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote>
<blockquote type="cite"><blockquote type="cite">The ThreadLocalToolkit class has a flex Logger object, which is stored<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">within a ThreadLocal<br></blockquote>
</blockquote><blockquote type="cite"><blockquote type="cite">object, which is a Java thing that creates local vars which are unique to a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">thread. The Logger object<br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite">holds the error count. So as long as each compile is done in a new thread,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
the error count<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">will get reset. Now, the question is whether each compile actually does<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">
happen in a new thread. I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">bet Tomcat has some kind of a thread pool, so I wonder if this is going to<br></blockquote></blockquote><blockquote type="cite">
<blockquote type="cite">cause confusion<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">at some point.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote>
</blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br>
</blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote>
<blockquote type="cite">-- <br></blockquote><blockquote type="cite">Henry Minsky<br></blockquote><blockquote type="cite">Software Architect<br></blockquote><blockquote type="cite"><a href="mailto:hminsky@laszlosystems.com" target="_blank">hminsky@laszlosystems.com</a><br>
</blockquote><br></div></blockquote></div><br></div></div><div class="Ih2E3d"><div> <span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<div><br>--</div><div><br>Don Anderson<br>Java/C/C++, Berkeley DB, systems consultant<br><br>voice: 617-547-7881<br>email: <a href="mailto:dda@ddanderson.com" target="_blank">dda@ddanderson.com</a><br>www: <a href="http://www.ddanderson.com/" target="_blank">http://www.ddanderson.com</a><br>
</div></div></span></span><br></div></span></div></span><br> </div><br></div></div></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Henry Minsky<br>Software Architect<br><a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br>
<br><br>
</div></div>