selv om MR og JRuby ideelt sett ville oppføre seg 100% det samme i alle situasjoner, er det noen mindre forskjeller. Noen forskjeller skyldes feil, og de er ikke rapportert her. Denne siden er for forskjeller som ikke er feil.
Stakk Spor Forskjeller
Fordi JRuby er EN jvm-basert språk, kan du se noen forskjeller i Hvordan Ruby stabel spor («backtraces») gjengis. En delvis liste over slike tilfeller er under:
- den» nye » rammen fra å bygge et objekt er kanskje ikke til stede på grunn av optimaliseringer.
- Kjerneklassemetoder implementert I Java vil vise en .java-fil og linjenummer hvor CRuby bare ville vise anropet .rb linje to ganger. Dette bør ikke påvirke utdataene
callerogcaller_locations. - det kan være flere eller færre rammer på grunn av hvordan vi rekonstruerer et stakkspor fra jvm-stakken.
- Nestede blokker vil ikke vise nivået av nesting.
- rammer På Øverste nivå kan vise et annet navn Der CRuby viser»».
generelt, kode bør ikke stole på unntak backtraces matchende CRuby nøyaktig, men når det er en tvilsom forskjell kan du åpne en bug. Vi prøver å matche CRuby så tett som mulig.
Opprinnelige C-Utvidelser
JRuby kan ikke kjøre opprinnelige c-utvidelser. Populære biblioteker har alle generelt blitt portet Til Java Innfødte Utvidelser. OGSÅ, nå SOM FFI har blitt et populært alternativ til binding Til c-biblioteker, bruker det unngår behovet for å skrive en stor del av innfødte utvidelser.
Fortsettelser Og Fibre
JRuby støtter ikke fortsettelser (Kernel.callcc).
Fibre (en form for avgrenset fortsettelse) støttes På JRuby, men hver fiber støttes av en innfødt tråd. Dette kan føre til ressursproblemer når du prøver å bruke flere fibre enn systemet tillater tråder i en gitt prosess.
Påkalle eksterne prosesser
På Microsoft Windows Er JRuby litt smartere når du starter eksterne prosesser. HVIS den kjørbare filen ikke er en binær kjørbar (.exe), KREVER MR at du også gir filens suffiks, Men JRuby klarer seg uten det.
si for eksempel at du har fil foo.bat på BANEN og vil kjøre den.
system( 'foo' ) # works on JRuby, fails on MRIsystem( 'foo.bat' ) # works both in JRuby and MRIGaffel er ikke implementert
JRuby implementerer ikke fork() på noen plattform, inkludert de der fork() er tilgjengelig I MR. Dette skyldes det faktum at de Fleste Jvmer ikke kan trygt forked.
Native Endian Er Big Endian
Siden JVM presenterer en kompatibel CPU Til JRuby, er den innfødte endianess Av JRuby Big Endian. Dette betyr noe for operasjoner som er avhengige av denne oppførselen, som String#unpack og Array#pack for formater som I, i, S, og s.
tidspresisjon
Siden det ikke er mulig å oppnå usec presisjon under EN JVM, kan Time.now.usec ikke returnere verdier med nanosekund presisjon. Dette er ikke lenger tilfelle under EN POSIX-plattform (siden JRuby 9.1).
irb(main):004:0> Time.now.usec=> 815414 På Windows er et innfødt systemkall ikke implementert, og dermed er DET JVM millisekund precision fallback.Vær oppmerksom på dette når du regner med usec presisjon i koden din.
> Time.now.usec=> 582000Trådprioritet
MERK: Fra minst like tidlig Som JRuby 1.7.6 er Ruby thread priorities kartlagt Til Java thread priorities, så denne delen er ikke nøyaktig-du kan bruke samme prioritet FOR MR og JRuby.
I MRI Kan Trådprioriteten settes til en hvilken som helst verdi i Fixnum (hvis innfødte tråder er aktivert) eller -3..3 (hvis ikke). Standardverdien er 0.
I JRuby støttes Tråder Av Java-tråder, og prioriteten varierer fra 1 til 10, med en standard på 5. Hvis du sender en verdi utenfor dette området til Thread#priority=, blir prioriteten satt til 1 eller 10.
MERK: AT JVM kan ignorere prioriteringer, er det egentlig avhengig av mål-OS og med (eldre) Java må du passere den ekstra -XX:UseThreadPriorities for at DE skal brukes.
SystemStackError
JRuby kan ikke redde fra SystemStackError. Hvis koden din stole på dette, bør du heller prøve å fange en Java::JavaLang::StackOverflowError. Se denne billetten for mer informasjon.
Argumentless’proc’
hvis du leverer proc uten argumenter og metoden skjer for å ha blitt bestått en blokk, Vil Ruby ende opp med å fange den bestått i blokk. Noen oppdager dette, og det fører til et sjeldent mønster på proc.call. Vi støtter ikke denne oppførselen. Problemet er proc som en funksjon er relativt vanlig, men det tvinger oss til å deoptimalisere all bruk av proc som proc { #some code }. Det anbefalte arbeidet er å erklære blokken eksplisitt ved hjelp av en ampersand def foo(&my_proc).... Hvis du vil ha analog oppførsel til proc, tillater vi også Proc.new som vil fungere akkurat det samme som en bare proc-samtale.
