One of the challenges when using the RTSJ is the lackThere are certainly issues that can arise when trying to use the standard libraries with both NoHeapRealtimeThreads (NHRT) and from ScopedMemory, but to say they are "unusable" is an over-statement and an over generalization.
of a standard class library. The rich Java API from
the standard edition is basically unusable because
java.lang, java.util, etc. were not designed for time
predictability and are not scope-safe.
Hmm... I'm curious how you feel about Javolution.I haven't looked at Javolution in any detail so I can't comment on what it does specifically.
Sounds like you're saying it solves a problem thatNo that wasn't what I said.
doesn't exist, since one can just use the standard
But the extra steps you mentioned (avoiding contextI believe that a certain discipline is needed in writing real-time code anyway, and checking for the above issues is just part of that. Minimizing sharing should be a goal regardless simply because of contention issues and priority inversion issues. Thinking about how to communicate between NHRTs and the rest of the application is something that should always be undertaken.
sharing, preventing collections from growing, etc.)
have a pretty big impact on productivity. Having to
do that extra work doesn't make the Java API very
Javolution, on the other hand,If it works well for you then go for it. Use the tools that best suit the job.
eliminates most of those steps.