Oprócz śmietnika, co jeszcze sprawia, że ​​Java nie jest językiem programowania w czasie rzeczywistym

Z wyjątkiem modułu wyrzucania elementów bezużytecznych, jakie są inne funkcje Java, które sprawiają, że nie nadaje się do programowania w czasie rzeczywistym? W sieci, ilekroć omawia się Javę kontra C ++ w odniesieniu do programowania w czasie rzeczywistym, zawsze wspomina się o śmieciarzu. Czy jest coś jeszcze?

Są dwa dodatkowe przedmioty, które pamiętam z ręki:

1. Kompilacja JIT
2. Implementacja wątków

W kontekście czasu rzeczywistego przewidywalność wydajności jest prawdopodobnie najważniejszym czynnikiem; Dlatego nieprzewidywalny cykl GC sprawia, że ​​Java nie nadaje się do pracy w czasie rzeczywistym.

JIT oferuje lepszą wydajność, ale uruchamia się w pewnym momencie po uruchomieniu programu, zabierając część zasobów i zmieniając szybkość wykonywania systemu. Może się to zdarzyć ponownie na późniejszym etapie, jeśli maszyna wirtualna uważa, że ​​w tym czasie może wykonać „lepszą” pracę.

Jeśli chodzi o wątki: nie do końca pamiętam, czy jest to część projektu języka, czy tylko bardzo powszechna implementacja, ale Java zwykle nie zapewnia narzędzi do precyzyjnej kontroli wykonywania wątków; Na przykład, chociaż dla wątków określono 10 „priorytetów”, nie ma wymogu, aby maszyna wirtualna faktycznie uwzględniała te priorytety. Operatory zatrzymujące i przełączające wątki również nie są zdefiniowane lub nie są ściśle przestrzegane przez system.

Istnieje kilka implementacji JSR 1: Specyfikacja w czasie rzeczywistym dla Java - specyfikacja zatwierdzona w 1998 r. Ta specyfikacja rozwiązuje w jak największym stopniu problemy, które sprawiają, że standardowa Java nie nadaje się do pracy w czasie rzeczywistym.

Być może 5 lat temu Sun (teraz Oracle) miał maszynę wirtualną RTSJ (która nigdy nie miała nazwy, AFAIK); IBM miał WebSphere Real Time; A JamaicaVM było darmowym (?) Niezależnym od platformy rozwiązaniem. Googlowanie dzisiaj nie przynosi wiele.

System operacyjny

Tak długo, jak Java działa na Uniksie, Windowsie lub jakimkolwiek innym „zwykłym” systemie operacyjnym, nie można zagwarantować działania w czasie rzeczywistym.

System operacyjny w czasie rzeczywistym jest obowiązkowy do uruchamiania aplikacji w czasie rzeczywistym.

Technicznie możliwe jest posiadanie java w czasie rzeczywistym (jak sugerują komentarze SK-logic). jednak nie jest to powszechne z wielu nietechnicznych powodów:

Stare standardy

Mam problem ze znalezieniem referencji na ten temat, ale jestem pewien, że widziałem standardy bezpieczeństwa lub porady dotyczące zgodności ze standardami bezpieczeństwa, wprowadziły ogólny zakaz Java. Słusznie lub nie, jeśli musisz dostosować się do czegoś, co mówi, że Java jest werbalna, wówczas Java jest werbalna.

Starzy inżynierowie bezpieczeństwa

Nawet jeśli standardy, które musisz podjąć, aby nie blokować Javy, praca z audytorami bezpieczeństwa / jakości bez doświadczenia w Javie w dużym stopniu oznacza, że ​​nie podążasz ścieżką najmniejszego oporu. Wszystko, co jest nietypowe dla audytora, prawdopodobnie przyciągnie wiele pytań, co z kolei oznacza wiele pracy dla ciebie uzasadniającej twój wybór.

Społeczność

tzn. istnieje duża zależność od ścieżki, większość obecnych ekspertów w czasie rzeczywistym zna C ++, C lub ADA na wylot, więc jest to naturalny wybór, aby wykonać nową pracę.

(uwaga: w pewnym stopniu połączyłem w czasie rzeczywistym i bezpieczeństwo, co jest poniekąd inną kwestią, ponieważ nawet normy bezpieczeństwa często łączą te dwa elementy)