Exceto coletor de lixo, o que mais faz do Java uma linguagem de programação não em tempo real

Exceto o coletor de lixo, quais são alguns outros recursos em Java que o tornam inadequado para programação em tempo real? Na rede, sempre que Java vs C ++ é discutido com relação à programação em tempo real, é sempre mencionado o coletor de lixo. Mais alguma coisa?

— Kaushik
fonte

Até a coleta de lixo não é um problema - existem vários coletores de lixo em tempo real disponíveis. Aqueles que mencionam o GC como uma rolha de show em tempo real são simplesmente incompetentes.

— SK-logic,

@ SK-logic s / incompetente / desinformado / g #

— Scott Whitlock

@ScottWhitlock, concordou, a maioria deles é. Mas alguns (os mais vocais) continuam insistindo mesmo após serem devidamente informados. Não conheço nenhuma explicação racional para esse fenômeno antropológico.

— SK-logic

Respostas:

Há dois itens adicionais que me lembro de imediato:

Compilação JIT
Implementação de encadeamento

Em termos de tempo real, a previsibilidade do desempenho é provavelmente o fator mais importante; É por isso que um ciclo imprevisível de GC torna o Java inadequado para tempo real.

O JIT oferece desempenhos aprimorados, mas é ativado em algum momento após a execução do programa, consumindo alguns recursos e alterando as velocidades de execução do sistema. Também pode acontecer novamente em um estágio posterior, se a VM acreditar que pode fazer um trabalho "melhor" naquele momento.

No que diz respeito ao encadeamento: neste momento, não me lembro se isso faz parte do design da linguagem ou apenas uma implementação muito comum, mas o Java geralmente não fornece ferramentas para controlar com precisão a execução do encadeamento; Por exemplo, embora existam 10 "prioridades" especificadas para threads, não há nenhum requisito de que a VM realmente considere essas prioridades. Os operadores para parar e alternar threads também não estão definidos ou não são rigidamente aderidos pelo sistema.

Existem várias implementações do JSR 1: Especificação em Tempo Real para Java - uma especificação que foi aprovada em 1998. Essa especificação aborda o máximo possível os problemas que tornam o Java padrão inadequado para o tempo real.

Há talvez cinco anos, a Sun (agora Oracle) tinha uma VM RTSJ (que nunca teve um nome, AFAIK); A IBM possuía o WebSphere Real Time; E o JamaicaVM era uma solução gratuita (?), Independente de plataforma. Pesquisar no Google hoje não traz muito.

— aviv
fonte

Outra questão, embora pequena em comparação, é que uma classe é carregada apenas quando será usada.

— T-Bull

Não há nada na especificação Java que imponha JIT em vez de AOT ou uma interpretação pura. Linhas verdes puras são totalmente previsíveis, portanto, elas também não podem ser um obstáculo em tempo real.

— SK-logic,

o tempo real da websphere pelo menos ainda parece ser suportado (reivindica o suporte ao Java 7.0 e você pode acessar uma página para comprá-lo)

— jk.

@ SK-logic - certo, bom ponto!

— aviv

O sistema operacional

Desde que o Java seja executado em cima do Unix ou Windows ou qualquer outro sistema operacional "regular", o tempo real não é garantido.

Um sistema operacional em tempo real é obrigatório para a execução de aplicativos em tempo real.

— mouviciel
fonte

@Giorgio: para garantias duras em tempo real? Sim.

— Joachim Sauer

Além disso, existem sistemas operacionais disponíveis projetados para o Tempo Real desde o início, por exemplo, FreeRTOS.

— Medivh

Embora esse seja um ponto muito importante para o tempo real difícil, em geral, ele não parece nem um pouco específico para Java. Estou esquecendo de algo?

@delnan o ponto é que, mesmo se você usar uma implementação (imaginária?) em tempo real de uma Java VM, não ajudará muito se o sistema operacional não puder fornecer garantias em tempo real.

— Schlingel

@delnan - A pergunta tem falsos pressupostos, sugerindo que o C ++ é uma linguagem de programação em tempo real.

— Mouviciel

Tecnicamente, é possível ter java em tempo real (como sugerem os comentários da SK-logic). no entanto, isso não é comum por várias razões não técnicas:

Padrões antigos

Tendo problemas para encontrar uma referência para isso, mas tenho certeza de que vi padrões de segurança ou conselhos de conformidade com padrões de segurança, proíbem o Java. Certo ou errado, se você precisar se adequar a algo que diz que Java é verboten, então Java é Verboten.

Engenheiros de segurança antigos

Mesmo que os padrões nos quais você precisa trabalhar para não banir o Java, trabalhar com auditores de Segurança / Qualidade sem experiência em Java signifiquem muito que você não esteja seguindo o caminho de menor resistência. Qualquer coisa fora do comum para o auditor provavelmente atrairá muitas perguntas, o que, por sua vez, significa muito trabalho para você justificar suas escolhas.

A comunidade

ou seja, existe muita dependência de caminho, a maioria dos especialistas atuais em tempo real conhecerá C ++, C ou ADA de dentro para fora, por isso é uma escolha natural fazer um novo trabalho.

(observação: conflitei um pouco com o tempo real e a segurança no item acima, o que é uma espécie de outro problema, pois até mesmo os padrões de segurança confundem os dois)

— jk.
fonte