Java under RTEMS --- status ??
charles.gauthier at nrc.ca
Wed Aug 30 14:59:40 UTC 2000
Joel Sherrill wrote:
> Charles-Antoine Gauthier wrote:
> > Rosimildo da Silva wrote:
> > >
> > > Guys,
> > >
> > > Where are we with the java ports ?
> > >
> > > + Kaffe --- I guess this is probably dead by now.
> > >
> > > + GJC ---
> > Almost done, I hope. We found that the code that pushes the registers
> > onto the gc mark stack does not work. We need to fix this. There were
> > some other issues that do not show up on most Unix systems but really
> > bugger up RTEMS.
> > As of today, I have a first successful run of all the tests in the
> > libjava testsuite on the MBX860. This does not include the mauve tests,
> > as they appear to require arguments (this was discovered by John on the
> > afternoon that he left to go back to school, and I have not investigated
> > yet).
> > === libjava Summary ===
> > # of expected passes 660
> > # of unexpected failures 182
> > # of unexpected successes 2
> > # of expected failures 372
> > runtest completed at Mon Aug 28 18:42:40 2000
> > 182 failures is not great. I have not compared against a run on the host
> > system, nor have I investigated those failures. We hope to push the code
> > back out into the community in the next two weeks.
> Just guessing ... are any of these doing file IO and you have
> default configuration values? Remember the miniIMFS and only
> 3 file descriptors is the new default.
That is not supposed to be the problem. We had to implement an
initialization task which calls the Java entry point to initialize the
Java environment and start the main Java thread. We also hacked the
jvgenmain tool which generates the Java entry point so that the function
name it spits out is dejagnu_main rather than main (once an
RTEMS-supplied init task that calls the user main function is provided,
this hack wont be required). The initialization task defines several
constants before including confdefs.h, including a higher number of fds.
The whole thing is provided as libdejagnu.a and gets linked in during
automated testing of Java applications.
But I do believe that we are using the dummy file system. Perhaps that
is a problem. I will investigate as soon as I get an chance.
> > All our changes need to be retrofitted to the current revision of
> > libgcj. That should not be a big issue. Whether or not it will work is
> > another question, as we have not been able to move forward successfully
> > since 2000-02-18. The last attempt was in late July, when we found the
> > back end code generators in gcc emitted back code.
> > >
> > > + J2ME ---
> > >
> > > Thanks in advance for the update.
> > > --
> > > Rosimildo da Silva rdasilva at connectel.com
> > > ConnectTel, Inc. Austin, TX -- USA
> > > Phone : 512-338-1111 Fax : 512-918-0449
> > > Mobile: 512-632-7579
> > > Company Page: http://www.connecttel.com
> > > Home Page: http://members.xoom.com/rosimildo/
> > --
> > Charles-Antoine Gauthier
> > Institute for Information Technology Institut de technologie de
> > l'information
> > National Research Council of Canada Conseil national de recherches du
> > Canada
> Joel Sherrill, Ph.D. Director of Research & Development
> joel at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
Institute for Information Technology Institut de technologie de
National Research Council of Canada Conseil national de recherches du
More information about the users