This content has been marked as final. Show 8 replies
Under windows you can not use cyclic drive even with virtual box as underline operating system should support cyclic drive. But you can use JRTS without cyclic drive still it gives you many functionality but real time is not guarantied (jitters and cycle misses). It is good only for run basic code and trials.
Note that if you run JavaRTS on a virtual machine, you may get a lot of jitter from the
host system anyway.
Unless you can guarantee that some CPUs are used only by the Solaris
layer, non real-time threads scheduled by your Host system may delay the real-time operations
within Solaris. This will of course disrupt your real-time Java threads. Even worse, this
may impact the cyclic subsystem, which controls all the fine grain time related operations in
Solaris (this is the low level module we interact with thanks to our cyclic driver to get better
In fact, even if you dedicate CPUs to Solaris, you also have to be careful with how Solaris
accesses to the 'hardware' time source. Virtualization could create some randomness in the
way Solaris perceives time, disrupting stuff sufficiently to be noticeable within JavaRTS/DTrace.
I highly recommend dual booting instead of using virtualization if you want to evaluate the
determinism of JavaRTS or the high precision of our DTrace based instrumentation tools.
JavaRTS Technical Leader
A couple of clarifications.
In Java RTS 1.0 there was a Netbeans module that allowed limited cross-development, but that is no longer supported. This is the module that the dead-link on netbeans.org would have lead to. The Netbeans module referred to in the Hands-on lab is only for use on Solaris 10 or Linux where you have an actual install of Java RTS 2.x available.
For Windows you would have to write your own stubbed out RTSJ classes, which would at least allow compilation and perhaps allow you to fake some RTSJ functionality for testing interaction with the non-RT part of your app (eg if you want to write the GUI in Netbeans etc).