jruby / jruby

selvom MR og JRuby ideelt set ville opføre sig 100% ens i alle situationer, er der nogle mindre forskelle. Nogle forskelle skyldes fejl, og de er ikke rapporteret her. Denne side er til forskelle, der ikke er fejl.

Stack Trace forskelle

da JRuby er et JVM-baseret sprog, kan du se nogle forskelle i, hvordan Ruby stack traces (“backtraces”) gengives. En delvis liste over sådanne tilfælde er nedenfor:

• den “nye” ramme fra konstruktion af et objekt er muligvis ikke til stede på grund af optimeringer.
• Core klasse metoder implementeret i Java vil vise en .java-fil og linjenummer, hvor CRuby bare ville vise opkaldet .RB linje to gange. Dette bør ikke påvirke caller og caller_locations output.
• der kan være flere eller færre rammer på grund af, hvordan vi rekonstruerer et stakspor fra JVM-stakken.
• indlejrede blokke viser ikke niveauet for nesting.
• rammer på øverste niveau kan vise forskellige navne, hvor CRuby viser “”.

generelt bør kode ikke stole på undtagelse backtraces matchende CRuby nøjagtigt, men når der er en tvivlsom forskel, skal du åbne en fejl. Vi forsøger at matche CRuby så tæt som muligt.

Native C-udvidelser

JRuby kan ikke køre native C-udvidelser. Populære biblioteker er alle generelt blevet porteret til Java-indfødte udvidelser. Også, nu hvor FFI er blevet et populært alternativ til binding til C-biblioteker, brug af det undgår behovet for at skrive en stor del af indfødte udvidelser.

fortsættelser og fibre

JRuby understøtter ikke fortsættelser (kerne.callcc).

fibre (en form for afgrænset fortsættelse) understøttes på JRuby, men hver fiber understøttes af en indfødt tråd. Dette kan føre til ressourceproblemer, når man forsøger at bruge flere fibre, end systemet tillader tråde i en given proces.

påkaldelse af eksterne processer

på Microsoft-vinduer er JRuby lidt smartere, når man starter eksterne processer. Hvis den eksekverbare fil ikke er en binær eksekverbar (.exe), kræver MR, at du også giver filsuffikset, men JRuby klarer sig uden det.

sig for eksempel, at du har fil foo.bat på din sti og vil køre den.

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

gaffel er ikke implementeret

JRuby implementerer ikke fork() på nogen platform, inklusive dem, hvor fork() er tilgængelig i Mr. Dette skyldes, at de fleste JVM ‘ er ikke kan forkes sikkert.

Native Endian er Big Endian

da JVM præsenterer en kompatibel CPU til JRuby, er jrubys native endianness Big Endian. Dette betyder noget for operationer, der afhænger af denne adfærd, som String#unpack og Array#pack for formater som I, i, S, og s.

tidspræcision

da det ikke er muligt at opnå usec præcision under en JVM, kan Time.now.usec ikke returnere værdier med nanosekundpræcision. Dette er ikke længere tilfældet under en POSITIONSPLATFORM (siden JRuby 9.1).

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

på vinduer er et indbygget systemopkald ikke implementeret, og der er således JVM millisekund precision fallback.Husk dette, når du regner med usec præcision i din kode.

> Time.now.usec=> 582000

Trådprioritet

bemærk: fra mindst så tidligt som JRuby 1.7.6 er Ruby trådprioriteter kortlagt til Java trådprioriteter, så dette afsnit er ikke korrekt-du kan bruge den samme prioritet til MR og JRuby.

i MR kan Trådprioriteten indstilles til en hvilken som helst værdi i Fiksnum (hvis native tråde er aktiveret) eller -3..3 (hvis ikke). Standardværdien er 0.

i JRuby understøttes tråde af Java-tråde, og prioriteten varierer fra 1 til 10 med en standard på 5. Hvis du overfører en værdi uden for dette interval til Thread#priority=, indstilles prioriteten til 1 eller 10.

bemærk: at JVM kan ignorere prioriteter, Det afhænger virkelig af mål OS og med (ældre) Java skal du passere den ekstra -XX:UseThreadPriorities for at de skal bruges.

SystemStackError

JRuby er ikke i stand til at redde fra SystemStackError. Hvis din kode er afhængig af dette, skal du hellere prøve at fange en Java::JavaLang::StackOverflowError. Se denne billet for yderligere information.

Argumentless ‘proc’

hvis du leverer proc uden argumenter, og metoden tilfældigvis er blevet bestået en blok, vil Ruby ende med at fange den passerede i blok. Nogle mennesker opdager dette, og det fører til et sjældent mønster på proc.call. Vi støtter ikke denne adfærd. Problemet er proc, da en funktion er relativt almindelig, men det tvinger os til at deoptimere alle anvendelser af proc som proc { #some code }. Det anbefalede arbejde er at erklære blokken eksplicit ved hjælp af et ampersand def foo(&my_proc).... Hvis du vil have Analog adfærd til proc, tillader vi også Proc.new, som fungerer nøjagtigt det samme som et bare proc-opkald.