jruby / jruby

Obwohl sich MRT und JRuby idealerweise in allen Situationen zu 100% gleich verhalten würden, gibt es einige geringfügige Unterschiede. Einige Unterschiede sind auf Fehler zurückzuführen, und diese werden hier nicht gemeldet. Diese Seite ist für Unterschiede, die keine Fehler sind.

Stack-Trace-Unterschiede

Da JRuby eine JVM-basierte Sprache ist, können einige Unterschiede in der Darstellung von Ruby-Stack-Traces („Backtraces“) auftreten. Eine unvollständige Liste solcher Fälle finden Sie unten:

• Der „neue“ Rahmen beim Konstruieren eines Objekts ist möglicherweise aufgrund von Optimierungen nicht vorhanden.
• In Java implementierte Kernklassenmethoden zeigen a.java-Datei und Zeilennummer, wo CRuby nur den Aufruf anzeigen würde.rb Linie zweimal. Dies sollte die Ausgabe von caller und caller_locations nicht beeinträchtigen.
• Es kann mehr oder weniger Frames geben, da wir einen Stack-Trace aus dem JVM-Stack rekonstruieren.
• Verschachtelte Blöcke zeigen die Verschachtelungsebene nicht an.
• Top-Level-Frames können einen anderen Namen zeigen, wo CRuby zeigt „“.

Im Allgemeinen sollte Code nicht auf Ausnahme-Backtraces angewiesen sein, die CRuby genau entsprechen, aber wenn es einen fragwürdigen Unterschied gibt, öffnen Sie bitte einen Fehler. Wir versuchen, CRuby so nah wie möglich zusammenzubringen.

Native C-Erweiterungen

JRuby kann keine nativen C-Erweiterungen ausführen. Beliebte Bibliotheken wurden alle in der Regel auf Java Native Extensions portiert. Jetzt, da FFI zu einer beliebten Alternative zur Bindung an C-Bibliotheken geworden ist, entfällt die Notwendigkeit, einen großen Teil nativer Erweiterungen zu schreiben.

Fortsetzungen und Fasern

JRuby unterstützt keine Fortsetzungen (Kernel.rufen Sie uns an).

Fasern (eine Form der begrenzten Fortsetzung) werden auf JRuby unterstützt, aber jede Faser wird von einem nativen Thread unterstützt. Dies kann zu Ressourcenproblemen führen, wenn versucht wird, mehr Fasern zu verwenden, als das System Threads in einem bestimmten Prozess zulässt.

Aufrufen externer Prozesse

Unter Microsoft Windows ist JRuby beim Starten externer Prozesse etwas intelligenter. Wenn die ausführbare Datei keine binäre ausführbare Datei ist (.exe), erfordert MRI, dass Sie auch das Dateisuffix angeben, aber JRuby kommt ohne es aus.

Angenommen, Sie haben die Datei foo.bat in Ihrem PFAD und möchten sie ausführen.

system( 'foo' ) # works on JRuby, fails on MRIsystem( 'foo.bat' ) # works both in JRuby and MRI

Fork ist nicht implementiert

JRuby implementiert fork() auf keiner Plattform, auch nicht auf Plattformen, auf denen fork() in MRI verfügbar ist. Dies liegt an der Tatsache, dass die meisten JVMs nicht sicher gegabelt werden können.

Native Endian ist Big Endian

Da die JVM eine kompatible CPU für JRuby darstellt, ist die native Endianness von JRuby Big Endian. Dies ist wichtig für Vorgänge, die von diesem Verhalten abhängen, wie String#unpack und Array#pack für Formate wie I, i, S, und s.

Zeitgenauigkeit

Da es nicht möglich ist, usec Genauigkeit unter einer JVM zu erhalten, kann Time.now.usec keine Werte mit Nanosekundengenauigkeit zurückgeben. Dies ist unter einer POSIX-Plattform (seit JRuby 9.1) nicht mehr der Fall.

irb(main):004:0> Time.now.usec=> 815414

Unter Windows ist ein systemeigener Systemaufruf nicht implementiert, und daher gibt es den JVM-Fallback mit Millisekundengenauigkeit.Denken Sie daran, wenn Sie in Ihrem Code auf die Genauigkeit von usec zählen.

> Time.now.usec=> 582000

Thread-Priorität

HINWEIS: Ab JRuby 1.7.6 werden Ruby-Thread-Prioritäten Java-Thread-Prioritäten zugeordnet, daher ist dieser Abschnitt nicht korrekt – Sie können dieselbe Priorität für RUBY und JRuby verwenden.

In MRI kann die Thread-Priorität auf einen beliebigen Wert in Fixnum (wenn native Threads aktiviert sind) oder -3 gesetzt werden..3 (falls nicht). Der Standardwert ist 0.

In JRuby werden Threads von Java-Threads unterstützt, und die Priorität reicht von 1 bis 10 mit einem Standardwert von 5. Wenn Sie einen Wert außerhalb dieses Bereichs an Thread#priority= übergeben, wird die Priorität auf 1 oder 10 gesetzt.

HINWEIS: Dass die JVM Prioritäten möglicherweise ignoriert, hängt wirklich vom Zielbetriebssystem ab, und bei (älterem) Java müssen Sie das zusätzliche -XX:UseThreadPriorities übergeben, damit sie verwendet werden können.

SystemStackError

JRuby kann nicht von SystemStackError retten. Wenn sich Ihr Code darauf verlässt, sollten Sie lieber versuchen, eine Java::JavaLang::StackOverflowError . Siehe dieses Ticket für weitere Informationen.

Argumentless ‚proc‘

Wenn Sie proc ohne Argumente angeben und der Methode zufällig ein Block übergeben wurde, erfasst Ruby am Ende den übergebenen Block. Einige Leute entdecken dies und es führt zu einem seltenen Muster von proc.call. Wir unterstützen dieses Verhalten nicht. Das Problem ist, dass proc als Funktion relativ häufig vorkommt, aber es zwingt uns, alle Verwendungen von proc wie proc { #some code } zu deaktivieren. Die empfohlene Problemumgehung besteht darin, den Block explizit mit einem kaufmännischen Und-Zeichen def foo(&my_proc)... zu deklarieren. Wenn Sie ein analoges Verhalten für proc möchten, erlauben wir auch Proc.new , das genauso funktioniert wie ein bloßer proc-Aufruf.