Excepto el recolector de basura, ¿qué más hace de Java un lenguaje de programación no en tiempo real?

Excepto el recolector de basura, ¿cuáles son algunas otras características en Java que lo hacen inadecuado para la programación en tiempo real? En la red, cada vez que se discute Java vs C ++ con respecto a la programación en tiempo real, siempre se menciona el recolector de basura. ¿Hay algo mas?

— Kaushik
fuente

Incluso la recolección de basura no es un problema: hay varios recolectores de basura en tiempo real disponibles. Aquellos que mencionan a gc como un show stopper en tiempo real son simplemente incompetentes.

— SK-logic

@ SK-logic s / incompetente / desinformado / g

— Scott Whitlock

@ScottWhitlock, de acuerdo, la mayoría lo son. Pero algunos (los más vocales) siguen insistiendo incluso después de estar debidamente informados. No conozco ninguna explicación racional para este fenómeno antropológico.

— SK-logic

Respuestas:

Hay dos elementos adicionales que recuerdo fácilmente:

Compilación JIT
Implementación de subprocesos

En términos de tiempo real, la previsibilidad del rendimiento es probablemente el factor más importante; Es por eso que un ciclo de GC impredecible hace que Java sea inadecuado para el tiempo real.

JIT ofrece mejores prestaciones, pero se activa en algún momento después de que el programa se está ejecutando, tomando algunos recursos y cambiando las velocidades de ejecución del sistema. También puede volver a ocurrir en una etapa posterior, si la VM cree que puede hacer un "mejor" trabajo en ese momento.

En cuanto a los subprocesos: en este momento no recuerdo si esto es parte del diseño del lenguaje, o simplemente una implementación muy común, pero Java generalmente no proporciona herramientas para controlar con precisión la ejecución de subprocesos; Por ejemplo, si bien hay 10 "prioridades" especificadas para los subprocesos, no hay requisito de que la VM realmente considere estas prioridades. Los operadores para detener y cambiar subprocesos tampoco están definidos o el sistema no los cumple rígidamente.

Hay varias implementaciones de JSR 1: Especificación en tiempo real para Java , una especificación que se aprobó en 1998. Esta especificación aborda en la mayor medida posible los problemas que hacen que Java estándar no sea adecuado para el tiempo real.

A partir de hace quizás 5 años, Sun (ahora Oracle) tenía una VM RTSJ (que nunca tuvo un nombre, AFAIK); IBM tenía WebSphere Real Time; Y JamaicaVM era una solución gratuita (?), Independiente de la plataforma. Buscar en Google esos hoy no trae mucho.

— aviv
fuente

Otro problema, aunque pequeño en comparación, es que una clase solo se carga cuando se va a usar.

— T-Bull

No hay nada en la especificación de Java que imponga JIT en lugar de AOT o una interpretación pura. Los hilos verdes puros son totalmente predecibles, por lo que tampoco pueden ser un obstáculo en tiempo real.

— SK-logic

websphere en tiempo real al menos todavía parece ser compatible (afirma que admite Java 7.0 y puede acceder a una página para comprarlo)

— jk.

@ SK-logic - correcto, buen punto!

— aviv

El sistema operativo

Mientras Java se ejecute sobre Unix o Windows o cualquier otro sistema operativo "normal", el tiempo real no está garantizado.

Un sistema operativo en tiempo real es obligatorio para ejecutar aplicaciones en tiempo real.

— Mouviciel
fuente

@Giorgio: ¿para garantías duras en tiempo real? Sí.

— Joachim Sauer

Además, hay sistemas operativos disponibles que están diseñados para tiempo real desde el principio, por ejemplo, FreeRTOS.

— medivh

Si bien este es un punto muy importante para el tiempo real en general, no parece ser específico de Java en lo más mínimo. ¿Me estoy perdiendo de algo?

@delnan el punto es que, incluso si usa una implementación en tiempo real (¿imaginaria?) de una máquina virtual Java, no ayuda mucho si el sistema operativo no puede brindarle garantías en tiempo real.

— schlingel

@delnan: la pregunta tiene premisas falsas, lo que sugiere que C ++ es un lenguaje de programación en tiempo real.

— Mouviciel

Técnicamente es posible tener Java en tiempo real (como sugieren los comentarios de SK-logic). sin embargo, no es común por varias razones no técnicas:

Normas antiguas

Tengo problemas para encontrar una referencia para esto, pero estoy seguro de que he visto estándares de seguridad, o consejos de conformidad con los estándares de seguridad, imponer una prohibición general a Java. Con razón o sin ella, si tiene que ajustarse a algo que dice que Java es verboten, entonces Java es Verboten.

Viejos ingenieros de seguridad

Incluso si los estándares que necesita para trabajar no prohíben Java, trabajar con auditores de Seguridad / Calidad sin experiencia en Java significará que no está siguiendo el camino de menor resistencia. Cualquier cosa que esté fuera de lo común para el auditor probablemente atraerá muchas preguntas, lo que a su vez significa mucho trabajo para justificar sus elecciones.

La comunidad

es decir, hay mucha dependencia de la ruta, la mayoría de los expertos actuales en tiempo real conocerán C ++, C o ADA de adentro hacia afuera, por lo que es una opción natural hacer un nuevo trabajo.

(nota: he combinado algo de tiempo real y seguridad en lo anterior, lo cual es otra cuestión, ya que incluso las normas de seguridad a menudo combinan los dos)

— jk.
fuente