Real-Time Java - Versionsgeschichte

InsightTheory: /* growthexperiments-addlink-summary-summary:3|0|0 */

2024-11-07T22:23:36Z

Linkvorschlag-Funktion: 3 Links hinzugefügt.

← Nächstältere Version		Version vom 8. November 2024, 00:23 Uhr
Zeile 8:		Zeile 8:
	Um diese Schwierigkeiten zu meistern, wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.		Um diese Schwierigkeiten zu meistern, wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.

	Aktuelle Umsetzungen der RTSJ ermöglichen es, in Java harte und weiche Echtzeitanwendungen zu entwickeln. Zu den bekanntesten Implementierungen gehört die Referenzimplementierung von Timesys, [[IBM]]s WebSphere Real Time, [[Sun Microsystems]] Java SE Real-Time Systems, Aonix PERC und JamaicaVM von aicas.		Aktuelle Umsetzungen der RTSJ ermöglichen es, in Java harte und weiche Echtzeitanwendungen zu entwickeln. Zu den bekanntesten Implementierungen gehört die [[Referenzimplementierung]] von Timesys, [[IBM]]s [[WebSphere]] Real Time, [[Sun Microsystems]] Java SE Real-Time Systems, Aonix PERC und JamaicaVM von aicas.

	== Entwicklung ==		== Entwicklung ==
	Der seit Java 9 bei Servern standardmäßig eingesetzte „Garbage first Garbage Collector“ (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>		Der seit Java 9 bei Servern standardmäßig eingesetzte „Garbage first Garbage Collector“ (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>

	Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref><ref>[https://wiki.openjdk.java.net/display/zgc] The Z Garbage Collector - Sub-millisecond max pause times</ref>		Seit längerem existieren auch Garbage-Collectors, die [[Algorithmus\|Algorithmen]] verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref><ref>[https://wiki.openjdk.java.net/display/zgc] The Z Garbage Collector - Sub-millisecond max pause times</ref>

	== Literatur ==		== Literatur ==

86.111.154.6: verstaendlicher; Typo

2024-06-23T08:45:04Z

verstaendlicher; Typo

← Nächstältere Version		Version vom 23. Juni 2024, 10:45 Uhr
Zeile 4:		Zeile 4:
	Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]], machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:		Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]], machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:
	* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].		* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].
	* Das Verhalten bestimmter Java Garbage Collectors kann ~~unbegrenzte~~ ~~Pausen~~ ~~bei~~ ~~Berechnungen~~ verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.		* Das Verhalten bestimmter Java Garbage Collectors kann Unterbrechungen unbegrenzter Dauer in der Programmausführung verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.

	Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.		Um diese Schwierigkeiten zu meistern, wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.

	Aktuelle Umsetzungen der RTSJ ermöglichen es, in Java harte und weiche Echtzeitanwendungen zu entwickeln. Zu den bekanntesten Implementierungen gehört die Referenzimplementierung von Timesys, [[IBM]]s WebSphere Real Time, [[Sun Microsystems]] Java SE Real-Time Systems, Aonix PERC und JamaicaVM von aicas.		Aktuelle Umsetzungen der RTSJ ermöglichen es, in Java harte und weiche Echtzeitanwendungen zu entwickeln. Zu den bekanntesten Implementierungen gehört die Referenzimplementierung von Timesys, [[IBM]]s WebSphere Real Time, [[Sun Microsystems]] Java SE Real-Time Systems, Aonix PERC und JamaicaVM von aicas.

Arilou: Die Technik heißt "Garbage Collection", der durchführende Codeteil "Garbage Collector". Nur von zweiterem kann es mehrere geben.

2021-05-27T07:05:10Z

Die Technik heißt "Garbage Collection", der durchführende Codeteil "Garbage Collector". Nur von zweiterem kann es mehrere geben.

← Nächstältere Version		Version vom 27. Mai 2021, 09:05 Uhr
Zeile 4:		Zeile 4:
	Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]], machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:		Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]], machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:
	* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].		* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].
	* Das Verhalten bestimmter Java Garbage ~~Collections~~ kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.		* Das Verhalten bestimmter Java Garbage Collectors kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.

	Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.		Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.
Zeile 11:		Zeile 11:

	== Entwicklung ==		== Entwicklung ==
	Der seit Java 9 bei Servern standardmäßig eingesetzte ~~Garbage~~ first Garbage ~~Collector~~ (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>		Der seit Java 9 bei Servern standardmäßig eingesetzte „Garbage first Garbage Collector“ (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>

	Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref><ref>[https://wiki.openjdk.java.net/display/zgc] The Z Garbage Collector - Sub-millisecond max pause times</ref>		Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref><ref>[https://wiki.openjdk.java.net/display/zgc] The Z Garbage Collector - Sub-millisecond max pause times</ref>

Sebastian.Dietrich: /* Entwicklung */ weiterer

2021-05-27T05:07:00Z

Entwicklung: weiterer

← Nächstältere Version		Version vom 27. Mai 2021, 07:07 Uhr
Zeile 13:		Zeile 13:
	Der seit Java 9 bei Servern standardmäßig eingesetzte Garbage first Garbage Collector (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>		Der seit Java 9 bei Servern standardmäßig eingesetzte Garbage first Garbage Collector (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>

	Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref>		Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref><ref>[https://wiki.openjdk.java.net/display/zgc] The Z Garbage Collector - Sub-millisecond max pause times</ref>

	== Literatur ==		== Literatur ==

Sebastian.Dietrich: aktualisiert, Unterscheidung zwischen weicher und harter Echtzeit, Vergangenheitsform, aktuelle GCs

2021-05-27T04:59:15Z

aktualisiert, Unterscheidung zwischen weicher und harter Echtzeit, Vergangenheitsform, aktuelle GCs

← Nächstältere Version		Version vom 27. Mai 2021, 06:59 Uhr
Zeile 1:		Zeile 1:
	'''Real-Time Java''' ist eine Sammlung von [[Programmierschnittstelle]]n, welche die [[Java (Technik)\|Java-Technologie]] um [[Echtzeit]]fähigkeiten erweitert. Diese ''Real-Time Specification for Java'' (RTSJ) wurde als [[Java Specification Request]] 1 im Rahmen des [[Java Community Process]] entwickelt und als Standard im November 2001 verabschiedet. Aktuell wird an einer erweiterten Version der RTSJ im Rahmen des JSR 282 gearbeitet.		'''Real-Time Java''' ist eine Sammlung von [[Programmierschnittstelle]]n, welche die [[Java (Technik)\|Java-Technologie]] um harte [[Echtzeit]]fähigkeiten erweitert. Diese ''Real-Time Specification for Java'' (RTSJ) wurde als [[Java Specification Request]] 1 im Rahmen des [[Java Community Process]] entwickelt und als Standard im November 2001 verabschiedet. Aktuell wird an einer erweiterten Version der RTSJ im Rahmen des JSR 282 gearbeitet.<ref>https://jcp.org/en/jsr/detail?id=282</ref>

	== Hintergründe ==		== Hintergründe ==
	Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]], ~~machen~~ eine direkte Verwendung von Java in Echtzeitsystemen unmöglich:		Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]], machten eine direkte Verwendung von Java in harten Echtzeitsystemen unmöglich:
	* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].		* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].
	* Das Verhalten ~~der~~ Java Garbage ~~Collection~~ kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.		* Das Verhalten bestimmter Java Garbage Collections kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.

	Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.		Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.
Zeile 11:		Zeile 11:

	== Entwicklung ==		== Entwicklung ==
			Der seit Java 9 bei Servern standardmäßig eingesetzte Garbage first Garbage Collector (G1GC) hat Zielvorgaben für die maximale Länge der Pausen, welche er bis auf seltene Ausnahmen auch erreicht. Damit sind weiche Echtzeitanwendungen in Java möglich.<ref>[https://www.oracle.com/technical-resources/articles/java/g1gc.html] Garbage First Garbage Collector Tuning, Monica Beckwith, August 2013</ref>
⚫	~~Mittlerweile~~ existieren auch Garbage-~~Collection-~~Algorithmen, ~~welche~~ ~~dennoch~~ harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref>

		⚫	Seit längerem existieren auch Garbage-Collectors, die Algorithmen verwenden, deren zeitliches Verhalten vorhersagbar ist und damit auch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref><ref>[https://www.ibm.com/docs/en/wxs/8.6.1?topic=time-websphere-real-in-websphere-application-server] WebSphere Real Time in WebSphere Application Server</ref><ref>https://www.azul.com/products/components/pgc/</ref>

	== Literatur ==		== Literatur ==

Sebastian.Dietrich: /* Entwicklung */ linkfix

2021-05-27T04:31:29Z

Entwicklung: linkfix

← Nächstältere Version		Version vom 27. Mai 2021, 06:31 Uhr
Zeile 11:		Zeile 11:

	== Entwicklung ==		== Entwicklung ==
	Mittlerweile existieren auch Garbage-Collection-Algorithmen, welche dennoch harte Echtzeit-Anwendungen in Java erlauben.<ref>[~~http~~://~~www~~.ibm.com/~~developerworks/library/j-rtj4~~/ Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref>		Mittlerweile existieren auch Garbage-Collection-Algorithmen, welche dennoch harte Echtzeit-Anwendungen in Java erlauben.<ref>[https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=175 Metronome-GC-Algorithmus] für harte Echtzeit-Java-Anwendungen; IBM; abgerufen am 12. Juni 2014</ref>

	== Literatur ==		== Literatur ==

Arilou: /* Hintergründe */ +kommas

2021-05-26T14:50:29Z

Hintergründe: +kommas

← Nächstältere Version		Version vom 26. Mai 2021, 16:50 Uhr
Zeile 2:		Zeile 2:

	== Hintergründe ==		== Hintergründe ==
	Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften wie die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]] machen eine direkte Verwendung von Java in Echtzeitsystemen unmöglich:		Einige der üblicherweise als Stärken von Java angesehenen Eigenschaften, wie beispielsweise die untrennbar mit der Sprache verbundene [[Garbage Collection]], sowie die native Unterstützung von [[Thread (Informatik)\|Threads]] und [[Nebenläufigkeit]], machen eine direkte Verwendung von Java in Echtzeitsystemen unmöglich:
	* Java unterstützt wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].		* Java unterstützt, wie die meisten der Betriebssysteme, für die Java angeboten wird, kein striktes auf [[Multitasking#Präemptives Multitasking\|Prioritäten]] basierendes Threading-Modell. Damit unterstützen die [[Lock]]-Mechanismen von Java keine Mechanismen zur Vermeidung der [[Prioritätsinversion]] wie beispielsweise [[Prioritätsgrenze]]n oder [[Prioritätsvererbung]].
	* Das Verhalten der Java Garbage Collection kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.		* Das Verhalten der Java Garbage Collection kann unbegrenzte Pausen bei Berechnungen verursachen und untergräbt somit alle Echtzeitgarantien von Javaprogrammen.

	Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java die obengenannten Hindernisse zu umgehen in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.		Um diese Schwierigkeiten zu meistern wurde die ''Real-Time Specification for Java'' (RTSJ) als [[Java Specification Request]] entwickelt. Sie ermöglicht es in Java, die obengenannten Hindernisse zu umgehen, in dem sie ein entsprechendes Threading-Modell einführt und es ermöglicht, die [[Java Virtual Machine]] durch weitere Threading-Modelle zu erweitern. Darüber hinaus definiert sie spezielle Speicherbereiche, welche nicht durch die herkömmliche Garbage Collection bereinigt werden, sondern durch realtimefähige Threads, welche nicht durch die Garbage Collection pausiert werden können.

	Aktuelle Umsetzungen der RTSJ ermöglichen es in Java harte und weiche Echtzeitanwendungen zu entwickeln. Zu den bekanntesten Implementierungen gehört die Referenzimplementierung von Timesys, [[IBM]]s WebSphere Real Time, [[Sun Microsystems]] Java SE Real-Time Systems, Aonix PERC und JamaicaVM von aicas.		Aktuelle Umsetzungen der RTSJ ermöglichen es, in Java harte und weiche Echtzeitanwendungen zu entwickeln. Zu den bekanntesten Implementierungen gehört die Referenzimplementierung von Timesys, [[IBM]]s WebSphere Real Time, [[Sun Microsystems]] Java SE Real-Time Systems, Aonix PERC und JamaicaVM von aicas.

	== Entwicklung ==		== Entwicklung ==

Aka: /* Literatur */ Tippfehler entfernt | …

2020-05-02T08:38:22Z

Literatur: Tippfehler entfernt | …

← Nächstältere Version		Version vom 2. Mai 2020, 10:38 Uhr
Zeile 41:		Zeile 41:
	\|Hrsg=Gregory Bollella		\|Hrsg=Gregory Bollella
	\|Titel=The Real-Time Specification for Java		\|Titel=The Real-Time Specification for Java
	\|Verlag=Addison Wesley Longman		\|Verlag=Addison-Wesley Longman
	\|Datum=2000		\|Datum=2000
	\|ISBN=0-201-70323-8		\|ISBN=0-201-70323-8

Aka: /* Weblinks */ Tippfehler entfernt

2020-03-23T16:25:57Z

Weblinks: Tippfehler entfernt

← Nächstältere Version		Version vom 23. März 2020, 18:25 Uhr
Zeile 53:		Zeile 53:
	* [http://java.sun.com/javase/technologies/realtime/rts/ Sun Java Real-Time System] – Real time Java Homepage		* [http://java.sun.com/javase/technologies/realtime/rts/ Sun Java Real-Time System] – Real time Java Homepage
	* [http://www.timesys.com/java/ Timesys RTSJ] – Referenzimplementierung und Testsystem von timesys		* [http://www.timesys.com/java/ Timesys RTSJ] – Referenzimplementierung und Testsystem von timesys
	* [http://jrate.sourceforge.net/ jRate (Java Real-Time Extension)] – eine ~~OpenSource~~ Erweiterung des GNU GCJ Compilers mit Unterstützung der meisten Features von RTSJ		* [http://jrate.sourceforge.net/ jRate (Java Real-Time Extension)] – eine Open-Source-Erweiterung des GNU-GCJ-Compilers mit Unterstützung der meisten Features von RTSJ
	* [https://www.aicas.com/cms/en/JamaicaVM JamaicaVM] – eine Implementierung der Real-Time Specification von aicas		* [https://www.aicas.com/cms/en/JamaicaVM JamaicaVM] – eine Implementierung der Real-Time Specification von aicas
	* [http://www.oracle.com/us/products/middleware/application-server/jrockit-real-time-ds-068267.pdf JRockit Real Time] (PDF; 62 kB) – Implementierung der Real-Time Specification von Oracle		* [http://www.oracle.com/us/products/middleware/application-server/jrockit-real-time-ds-068267.pdf JRockit Real Time] (PDF; 62 kB) – Implementierung der Real-Time Specification von Oracle

Aka: Tippfehler entfernt

2020-03-17T20:01:28Z

Tippfehler entfernt

← Nächstältere Version		Version vom 17. März 2020, 22:01 Uhr
Zeile 1:		Zeile 1:
	'''Real-Time Java''' ist eine Sammlung von [[Programmierschnittstelle]]n, welche die [[Java (Technik)\|Java Technologie]] um [[Echtzeit]]fähigkeiten erweitert. Diese ''Real-Time Specification for Java'' (RTSJ) wurde als [[Java Specification Request]] 1 im Rahmen des [[Java Community Process]] entwickelt und als Standard im November 2001 verabschiedet. Aktuell wird an einer erweiterten Version der RTSJ im Rahmen des JSR 282 gearbeitet.		'''Real-Time Java''' ist eine Sammlung von [[Programmierschnittstelle]]n, welche die [[Java (Technik)\|Java-Technologie]] um [[Echtzeit]]fähigkeiten erweitert. Diese ''Real-Time Specification for Java'' (RTSJ) wurde als [[Java Specification Request]] 1 im Rahmen des [[Java Community Process]] entwickelt und als Standard im November 2001 verabschiedet. Aktuell wird an einer erweiterten Version der RTSJ im Rahmen des JSR 282 gearbeitet.

	== Hintergründe ==		== Hintergründe ==