Jarosław Zabiełło - BLOG: Tag java

JRuby - metoda initialize i Java

Jarosław Zabiełło — Thu, 14 Aug 2008 04:38:00 +0200

Ostatnio, podczas próby użycia javowej biblioteki w JRuby spotkałem problem z kolizją nazw metod Javy z metodami Rubiego. Mianowicie chodzi o metodę o nazwie initialize jaka była zdefiniowana w bibliotece Javy. W JRuby (i Ruby) nazwa ta jest zarezerwowana dla konstruktora. Dzięki temu, że miałem dostęp do źródeł w Javie, mógłbym po prostu je zmodyfikować. Jednakże, takie podejście nie za bardzo mi się podobało. Co w wypadku kiedy miałbym bibliotekę dostępną tylko w postaci skompilowanych klas?

Przeczesując internet, nie znalazłem nic na ten temat. W bugtrackerze JRuby można znaleźć dwa tickety (45 i 2799) które wspominają o tym problemie, lecz nie dostarczają żadnego rozwiązania. W tym drugim podano niby obejście problemu, tylko że błędne (dopisalem tam swoją uwagę). Poprawne rozwiązanie otrzymałem od Marcina Mielżyńskiego (developera JRuby) na grupie pl.comp.lang.ruby.

package pl.foo.bar;
public class X {
    public void initialize() {
        System.out.println("foo");
    }
}

include Java
require 'X.jar'

X = Java::PlFooBar::X
jcls = X.java_class
m = jcls.declared_method("initialize")
m.invoke(X.new.java_object)

Zainspirowany tym podejściem postanowiłem napisać bardziej ogólne rozwiązanie tego typu problemów.

W komentarzach do ticketu 2799 padła sugestia, aby stworzyć dodatkową metodę java_call o sugerowanej, następującej składni:

result = my_inst.java_call :my_method, 'an arg or', 2

Niestety, taki pomyśl raczej nie wypali z powodu specyfiki Javy. W przeciwieństwie do Rubiego, Java nie używa unikalnych nazw metod, ale stosuje ich przeciążanie. Java rozróżnia także typy prymitywne int, float, boolean od obiektów Integer, Float czy Boolean. Mimo, że te drugie są co prawda wrapperami dla prymitywów, jeśli jakaś biblioteka Javy posiada dwie metody o tej samej nazwie ale różniące się typem int vs. Integer, to JRuby nie za bardzo będzie wiedzieć którą metodę ma wybrać (w Ruby nie ma prymitywów, wszystko jest obiektem na tych samych prawach). Np. załóżmy, że mamy bibliotekę o takim kodzie:

public class Tescior {
    public void initialize() {
        System.out.println("initialize is reserved for constructor in JRuby");
    }
    public void initialize(String name) {
        System.out.println("Hello " + name);
    }
    public void initialize(Integer x, Integer y) {
        System.out.printf("%s + %s = %s\n", x,y,(x+y));
    }
    public void initialize(int x, Integer y) {
        System.out.printf("%s + %s = %s\n", x,y,(x+y));
    }
}

Jak niby składnia my_inst.java_call(:initialize, 3, 4) ma wiedzieć czy chodzi o powyższą metodę 3, czy 4? Nie da się! Aby to obejść, należy przekazywać nazwy typów. Dopiero gdy znamy nazwę metody i typy jej argumentów możemy jednoznacznie w Javie określić o jaką metodę nam chodzi.

Skompilujmy z konsoli powyższy kod Javy i stwórzmy jar’a.

$ javac Tescior.java
$ zip Tescior.jar Tescior.class

Kod JRuby i przykład użycia:

include Java

require 'Tescior.jar'
include_class 'Tescior'

class Java::JavaLang::Object
  def java_call(method_name, *params)
    jcls = self.java_class
    m = jcls.declared_method method_name, *params.map{|x| x[0]}
    m.invoke self.java_object, *params.map{|x| Java.ruby_to_java(x[1])}
  end
end

# test
Tescior.new.java_call :initialize
Tescior.new.java_call :initialize, [java.lang.String, "Jarek!"]
Tescior.new.java_call :initialize, [:int, 3], [java.lang.Integer, 4]
Tescior.new.java_call :initialize, [java.lang.Integer, 6], [java.lang.Integer,7]

Jak widać, przekazywane są typy i wartości parametrów. JRuby wszystkie typy prymitywne przekazuje za pomocą symboli. Pozostałe są przekazywane przez java.lang i są zgodne z javowym API. Powyższy kod można troszkę uprościć. Po co pisać takie długie deklaracje, skoro można prościej wiedząc że wszystkie nazwy klas Javy zaczynają się z dużej litery. Mimo, że to nie jest wymóg języka (tak jak jest to w Ruby) ta konwencja jest konsekwentnie stosowana i to wystarczy.

class Java::JavaLang::Object
  def java_call(method_name, *params)
    jcls = self.java_class
    m = jcls.declared_method(method_name, *params.map do |x|
      x[0].to_s =~ /^[A-Z]/ ? eval("java.lang.#{x[0]}"): x[0]
    end)
    m.invoke self.java_object, *params.map{|x| Java.ruby_to_java(x[1])}
  end
end
# test:
Tescior.new.java_call :initialize
Tescior.new.java_call :initialize, [:String, "World!"]
Tescior.new.java_call :initialize, [:int, 7], [:Integer, 8]
Tescior.new.java_call :initialize, [:Integer, 9], [:Integer,10]

Ten zapis jest już dużo lepszy i zgodny z filozofią Javy. Aby wiedzieć o jaką metodę chodzi, potrzebna jest nie tylko jej nazwa ale i typy jej parametrów formalnych. Prawdę mówiąc, dzięki JRuby zaczynam nawet lubić Javę. Dostęp do potężnych bibliotek ale w ludzki, przyjazny sposób.

Ruby, Python i natywne wątki systemu operacyjnego

Jarosław Zabiełło — Sat, 26 Jul 2008 13:22:00 +0200

Wiele się mówi o tym, że Ruby jak i Python nie posiadają obsługi natywnych wątków systemu operacyjnego. Wbudowane, tzw. green threads, nie są w stanie wykorzystać zalet maszyn wyposażonych w procesory wielordzeniowe. Istnieją jednak implementacje obu języków w czystej Javie. Czy ich użycie daje jakieś znaczące przyśpieszenie?

Wszystkie testy były wykonywane na MacBook Pro Core2 Duo 2.16GHZ, 4GB RAM i systemie Mac OS X 10.5.4 Leopard + zainstalowana Java 1.6.0_05.

Python

from time import time
from random import Random
from threading import Thread
rand = Random().randint # alias

class Test(Thread):
   def __init__ (self): 
      Thread.__init__(self)
      print "Starting %s" % self.getName()
   def run(self): 
      a = [rand(0,SIZE) for x in xrange(SIZE)]
      a.sort()
      print "%s finished" % self.getName()      

print "Start"
start = time()
THREADS, SIZE = 20, 100000
threads = []             
for i in xrange(THREADS):
    t = Test()
    threads.append(t)
    t.start()     
while True in [t.isAlive() for t in threads]:
    pass
print "Time: %s s" % (time() - start)

Dla powyższego kodu Python i Jython uzyskały wyniki:

Jython 2.2.1 = 12.15 s.
Python 2.5.2 = 14.24 s.

Rożnica jakoś podejrzanie mała wskazująca na wciąż jeszcze niedojrzałą implementację Jythona. Dla pewności, zmodyfikowałem kod tak, aby korzystał z natywnych bibliotek Javy.

from time import time
from random import Random
rand = Random().randint # alias
from java.lang import Thread, Runnable

class Test(Runnable):
   def __init__ (self): 
      print "Starting %s" % self
   def run(self):         
      a = [rand(0,SIZE) for x in xrange(SIZE)]
      a.sort()  
      print "%s finished" % self

print "Start"
start = time()
THREADS, SIZE = 20, 100000    
threads = []             
for i in xrange(THREADS):
    t = Thread(Test())              
    threads.append(t)
    t.start()     
while True in [t.isAlive() for t in threads]:
    pass
print "Time: %s s" % (time() - start)

Tym razem

Jython 2.2.1 = 11.96 s.

Różnica jest minimalna. Na dodatek panuje trochę zamieszania co do sposobu odpalania wątków w Jythonie – mętna składnia i za dużo możliwych sposobów uzyskania tego samego efektu. Po SQLAlchemy, Jython jest kolejnym przykładam całkowitej ignorancji założeń języka Python (o istnieniu jednej, oczywistej drogi do tego samego celu). Na domiar złego, mój pierwotny test zakładał testowanie miliona liczb do sortowania. Jython nie był w stanie tego testu wykonać z powodu braku pamięci dla Javy. Ruszył dopiero jak mu zaalokowałem 1GB (słownie: jeden gigabajt pamięci) za pomocą opcji (-Xmx1024M), co jest po prostu chore! Po wymianie pierwotnego range() na generatorowy xrange() zapotrzebowanie na pamięć wyraźnie zmalało i wystarczyła już opcja -Xmx256M. Jednakże kod się wykonywał tak koszmarnie wolno, że nie starczyło mi cierpliwości i zmniejszyłem ilość iteracji do 100 tys.

Ruby

require "time"
require "thread"

THREADS, SIZE = 20, 100_000

start = Time.now
puts "Start"
threads = (1..THREADS).map do |i|
  puts "Starting Thread-#{i}\n"
  Thread.new(i) do |t|
    a = (1..SIZE).map {|e| rand(SIZE)}
    a.sort!
    puts "Thread-#{t} ended\n"
  end
end
while t = threads.find {|lt| lt.alive?}
  t.join
end 
puts "Time: #{Time.now - start} s."

Pierwsze, co mi się od razu rzuca w oczy, to o wiele czytelniejsza, zgrzebniejsza składnia Rubiego, który tu korzysta z bloków kodu. Po drugie, wyniki są dosyć ciekawe:

Ruby 1.9.0 = 1.11 s
Ruby Enterprise = 2.77 s
JRuby 1.1.2 = 3.53 s
Ruby 1.8.7 = 21.82 s.

Ruby okazał się najwolniejszy w tym zestawieniu. Python był tylko trochę szybszy. JRuby, korzystający z javowych wątków systemowych, zdeklasował Rubiego, Pythona i niedojrzałego Jythona. Jednakże to nie JRuby okazał się tu zwycięzcą. Nie trzeba czekać na Ruby 2.0, wersja 1.9 posiada już natywną obsługę wątków POSIX i jest dodatkowo nieźle zoptymalizowana. Ruby 1.9 pokazał, że jest tu prawie 4x szybszy od JRuby. Nie sądzę, że tą szybkość uzyskał na lepszej implementacji wątków od Javy. Raczej ma mocno zoptymalizowany kod który był wykonywany w każdym z wątków.

Bardzo dobrze poradził sobie też Ruby Enterprise, zoptymalizowana wersja Ruby 1.8.6 przez twórców Passengera! Nie wiem jakim cudem Ruby Enterprise pobił JRubiego… no chyba, że jego twórcy dodali mu obsługę natywnych wątków systemu operacyjnego. Inaczej nie mogę sobie wytłumaczyć tak dobrego wyniku.

Updated

Dla pełniejszego obrazu uruchomiłem testy dla 1 wątku. Poprawiłem też błąd z ilością list do sortowania faworyzującą Rubiego. Ostateczne podsumowanie wygląda tak:

1 thread, 2,000,000 iterations

Ruby 1.9 = 1.69 s.
Ruby Enterprise = 3.38 s.
JRuby 1.1.2 = 7.06 s.
Jython 2.2.1 = 17.29 s.
Python 2.5.2 = 18.06 s.
Ruby 1.8.7 = 22.37 s.

20 threads * 100,000 iterations

Ruby 1.9 = 1.54 s.
Ruby Enterprise = 3.01 s.
JRuby 1.1.2 = 5.82 s.
Jython 2.2.1 = 11.86 s.
Python 2.5.2 = 12.32 s.
Ruby 1.8.7 = 22.68 s.

Czasy, kiedy Python był zawsze szybszy od Rubiego, to już przeszłość. Z wyników wynika, że to nie obsługa wątków zadecydowała o wynikach. Ruby 1.9 pobił wszystkich zarówno w teście 1 jak i wielu wątków.

Updated 2008-07-30

Poprawiłem trochę test, aby nie zużywał tyle pamięci. Wyrzuciłem więc generowanie list i sortownie. Zostało samo generowanie losowych liczb. Dodałem też kod dla Javy dla porównania.

Java

import java.util.Random;

public class Main {

  static Integer SIZE,  ITERATIONS;

  public static void main(String[] args) throws Exception {
    Integer[] threads_nr = {1, 10, 50, 100};
    SIZE = Integer.parseInt(args[1]);
    System.out.println(args[0]);
    for(Integer nr: threads_nr) {
      ITERATIONS = SIZE / nr;
      System.out.printf(" %3d thread(s) x %9s = ", nr, ITERATIONS);
      long start = System.currentTimeMillis();
      Thread[] threads = new Thread[nr];
      for(int i = 0; i < threads.length; i++) {
        threads[i] = new ThreadTest();
        threads[i].start();
      }
      while(threadsAlive(threads)) {}
      System.out.printf("%s s.\n", (System.currentTimeMillis() - start) / 1000.0);
    }
  }

  public static boolean threadsAlive(Thread[] threads) {
    for(Thread t: threads)
      if(t.isAlive())
        return true;
    return false;
  }

  static class ThreadTest extends Thread {

    @Override
    public void run() {
      Random rnd = new Random();
      for(int i = 0; i < ITERATIONS; i++)
        rnd.nextInt(SIZE);
    }
  }
}

Test:

$ java Main "`java -version`" 10000000
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13-120)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_05-b13-52, mixed mode)
  1 thread(s) x  10000000 = 0.361 s.
 10 thread(s) x   1000000 = 0.18 s.
 50 thread(s) x    200000 = 0.186 s.
100 thread(s) x    100000 = 0.189 s.

Java, co nie dziwi, jest najszybsza. Nie ma znaczącej różnicy między 10 czy 10 wątkami, bo mój procesor posiada tylko dwa rdzenie.

Ruby/JRuby

require "time"
require "thread"

SIZE = ARGV[1].to_i  
puts ARGV[0]   
[1, 10, 50, 100].each do |nr|
  iterations = SIZE / nr
  print " %3d thread(s) x %9s = " % [nr, iterations]
  start = Time.now
  (1..nr).map do |i|
    Thread.new(i) do |t|
      iterations.times {rand(SIZE)}
    end
  end.each {|t| t.join}
  puts Time.now - start
end

Ten sam kod w Ruby/JRuby wygląda znacznie krócej (i ładniej) ale kosztem wydajności. To też nie dziwi. Ruby jest bardzo produktywnym językiem, lecz oczywiście nie tak szybkim jak Java.

Wyniki testów:

Ruby 1.9:

$ ruby1.9 main.rb "`ruby1.9 -v`" 10_000_000
ruby 1.9.0 (2008-06-20 revision 17482) [i686-darwin9.4.0]
  1 thread(s) x  10000000 = 2.858588
 10 thread(s) x   1000000 = 2.832928
 50 thread(s) x    200000 = 2.845377
100 thread(s) x    100000 = 2.852745

JRuby:

$ jruby main.rb "`jruby -v`" 10_000_000
jruby 1.1.3 (ruby 1.8.6 patchlevel 114) (2008-07-28 rev 6586) [x86_64-java]
   1 thread(s) x  10000000 = 3.58
  10 thread(s) x   1000000 = 3.4290000000000003
  50 thread(s) x    200000 = 3.442
 100 thread(s) x    100000 = 3.516

Ruby Enterprise:

$ ruby-enterprise main.rb "`ruby-enterprise -v`" 10_000_000
ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-darwin9.4.0]
  1 thread(s) x  10000000 = 3.510694
 10 thread(s) x   1000000 = 3.552756
 50 thread(s) x    200000 = 3.586885
100 thread(s) x    100000 = 3.574564

Ruby 1.8.6 (installed with Leopard):

$ /usr/bin/ruby main.rb "`/usr/bin/ruby -v`" 10_000_000
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
   1 thread(s) x  10000000 = 6.586917
  10 thread(s) x   1000000 = 6.78801
  50 thread(s) x    200000 = 6.951003
 100 thread(s) x    100000 = 6.907087

Ruby 1.8.7 (installed from MacPorts):

$ ruby main.rb   "`ruby -v`" 10_000_000
ruby 1.8.7 (2008-06-20 patchlevel 22) [i686-darwin9.4.0]
   1 thread(s) x  10000000 = 36.329174
  10 thread(s) x   1000000 = 36.808753
  50 thread(s) x    200000 = 36.715717
 100 thread(s) x    100000 = 36.499772

To co niepokoi, to koszmarnie wolna praca Ruby 1.8.7 w porównaniu do Ruby 1.8.6. To jest bardzo podejrzana sprawa. Cieszy za to dobra wydajność Ruby Enterprise.

Python/Jython

from random import Random
from sys import argv
from time import time
from threading import Thread
rand = Random().randint # alias

class ThreadTest(Thread):
   def __init__ (self, iterations): 
      Thread.__init__(self)              
      self.iterations = iterations
   def run(self): 
      [rand(0,SIZE) for x in xrange(self.iterations)]

SIZE = int(argv[2])
print argv[1]
for nr in [10, 50, 100]:
  iterations = SIZE / nr
  print " %3d thread(s) x %9s = " % (nr, iterations),
  start = time()
  threads = []
  for i in range(nr):
     t = ThreadTest(iterations)
     threads.append(t)
     t.start()
  for t in threads:
     t.join()
  print "%s s." % (time() - start)

Test:

$ python main.py "`python -V`" 10000000
Python 2.5.2
  1 thread(s) x  10000000 =  34.5188429356 s.
 10 thread(s) x   1000000 =  52.3496830463 s.
 50 thread(s) x    200000 =  53.9406650066 s.
100 thread(s) x    100000 =  58.3923280239 s.

Co ciekawe, Python 2.5.2 okazał się najwolniejszy. Im więcej wątków tym jeszcze wolniej działał. Był wolniejszy nawet od (dziwnie wolnego) Ruby 1.8.6. Ale, być może to jest wina bardzo wolnej biblioteki generowania losowych liczb. Ech, jak tu cokolwiek porównywać między językami jak takie odkrywa się takie babole w bibliotece standardowej Pythona.

Jython był jeszcze wolniejszy. Dla 10 mln. iteracji, mimo że nie były tworzone w pamięci żadne listy, wlókł się tak wolno, że przerwałem test. Po zmniejszeniu iteracji o rząd wielkości (do 1 miliona) uzyskał wyniki takie jak Ruby 1.8.6 dla 10 milionów iteracji. Jython jest najwyraźniej jeszcze bardzo słabo zoptymalizowany. Pomysły aby na nim odpalać frameworki takie jak Django, to na razie raczej przedwczesny pomysł.

Iterations: 1,000,000 instead of 10,000,000:

$ jython main.py "`jython --version`" 1000000
Jython 2.2.1 on java1.6.0_05

  10 thread(s) x    100000 =  6.391000032424927 s.
  50 thread(s) x     20000 =  4.368000030517578 s.
 100 thread(s) x     10000 =  4.352999925613403 s.

JRuby 1.1 final

Jarosław Zabiełło — Mon, 31 Mar 2008 00:51:00 +0200

Jest w końcu oczekiwana wersja stabilna JRuby 1.1. W chwili pisania tej notki, nie ma o tym jeszcze informacji na stronie głównej, ale jest już do pobrania. To bardzo dobra wiadomość, bo JRuby 1.1 już w wersjach rozwojowych był znacznie szybszy od poprzedniej 1.0, a w wielu testach bił wydajnością nie tylko Ruby 1.8.6 i 1.9, ale także Pythona 2.5.1. Dzięki JRuby webowe frameworki takie jak Rails czy Merb uzyskują pełny dostęp do bibliotek Javy i tym samym jakiekolwiek uwagi co do (nie)dojrzałości bibliotek Rubiego stają się nieistotne.

Django on Jython

Jarosław Zabiełło — Tue, 08 Jan 2008 04:34:00 +0100

Pythonistas chyba pozazdrościli możliwości odpalenia Railsów w JRuby. Trwają prace nad uruchomieniem frameworka Django w Jythonie, implementacji Pythona w czystej Javie.

Zapytałem się na kanale #pylons odnośnie podobnego ruchu ze strony Pylons, ale okazuje się że Jython jest dosyć zacofany. Od czasu przejścia jego twórcy do Microsoftu i pracy na IronPythonem projekt dosyć powoli się rozwija. Jython zatrzymał się na implementacji Pythona 2.2. To dosyć stara wersja zważając, że w międzyczasie wyszły wersje 2.3, 2.4 i 2.5. Pylons wymaga zgodności min. z Pythonem 2.4. Nie wiem jak ten problem rozwiążą przy przenoszeniu Django, bo coś nie chce mi się wierzyć że jest w pełni zgodny ze starym Pythonem 2.2.

Jest w końcu Java 6 dla Leoparda

Jarosław Zabiełło — Fri, 30 Nov 2007 12:34:00 +0100

Zarówno Apple jak i Sun się ociągają z wypuszczeniem Javy 6 dla Leoparda (tj. Mac OS-X 10.5). W internecie można znaleźć trochę wkurzonych osób. Niektórzy chcą nawet słać petycje do Apple aby coś z tym zrobili.

Na szczęście, znalazł się jeden człowiek (Landon Fuller) który udostępnił Javę 6 dla Leoparda. Gwoli ścisłości, przygotował zarówno wersję 32 bitową dla Tigera i Leoparda jak i wersję 64-bitową (tylko dla Leoparda). Choć plik zawiera w nazwie słowo “amd64”, nie należy się tym przejmować. Działa bez problemu na MacIntelach.

JRuby 1.0

Jarosław Zabiełło — Wed, 13 Jun 2007 11:24:00 +0200

Ukazała się finalna wersja JRuby 1.0 – implementacji języka Ruby w czystej Javie. Zespół JRuby zachęca do testowania Railsów na JRuby. Z tego co pamiętam, to wersji finalnej JRuby zapowiadano włączenie optymalizacji kodu. Zanim zatem wyjdzie w końcu Ruby 2.0, JRuby on Rails ma już teraz szansę przełamać stereotyp o słabszej wydajności Rubiego. Szczególnie może to mieć duże znaczenie dla platformy Windows, bo Ruby na systemach POSIX (Linux, BSD, Mac OS X) pracuje znacznie wydajniej.

Dla miłośników Mac OS X jest dostępny artykuł pokazujący jak skonfigurować całe środowisko Javy dla Rail. Ale do pracy z Rails, najprościej użyć Netbeans 6 który od jakiegoś czasu pozwala¹ na uruchamianie Railsów na JRuby (można wybrać sobie opcję JRuby lub klasyczny CRuby).

Zobacz też artykuł “JRuby and the Java Platform” jaki ukazał się wczoraj na stronie firmy Sun.

¹ Szkoda, że NB6 nie ma jeszcze zaimplementowanego kolorowania i podpowiadania helperów dla Haml. Jak ktoś ma siły i czas to tu jest opis jak dodać kolorowanie dla jakiegoś innego języka.

Jython 2.2beta1

Jarosław Zabiełło — Fri, 09 Feb 2007 22:51:00 +0100

Pogłoski o przedwczesnej śmierci Jythona (javowej implementacji Pythona), są chyba przesadzone. Właśnie wyszła kolejna wersja 2.2 beta1. Instalacja:

java -jar jython_installer-2.2b1.jar

Serwery kontynuacyjne - przyszłość webu

Jarosław Zabiełło — Wed, 22 Nov 2006 02:26:00 +0100

Każdy, kto zajmował się kiedykolwiek programowaniem stron internetowych wie, że protokół HTTP jest bezstanowy. Innymi słowy, każde przeładowanie strony internetowej generuje kompletnie niezależne wywołanie serwera i nie ma on możliwości aby powiązać wywołanie z konkretnym klientem. Aby temu zaradzić, wprowadzono prostą sztuczkę. Wprowadzono tzw. mechanizm cookies (dosł. ciasteczek), malutkich plików które serwer może wysyłać do klienta (tam i z powrotem). Ten unikalny identyfikator (sesji) można też trzymać w adresie URL, ale ta metoda jest zdecydowanie odradzana z powodu łatwości nadużyć (łatwo wykraść taki numer i podszyć się pod autora) Od strony klienta jedynym wymaganiem jest aby nie blokował sobie w przeglądarce mechanizmu cookies.

Serwer znając identyfikator sesji, może związać z nim szereg danych, np. aktualną listę zamawianych produktów włożonych do koszyka w sklepie internetowym. Dane te zwykle trzyma się w bazie lub w pamięci operacyjnej. Oczywiście czas życia danych jest ustalany przez serwet i w normalnym wypadku są one cyklicznie kasowane. (Z tym “normalnym” wypadkiem to różnie bywa, bo wiele frameworków tego nie zapewnia i trzeba samemu o to zadbać)

Mechanizm sesji jest dosyć wydajny, bo zapytania wysyłane do serwera mogą być obsługiwane asynchronicznie, czyli bez żadnych blokad w oczekiwaniu na ukończenie obsługi zapytania. Przez lata “stanowość” protokołu HTTP zapewniało się właśnie za pomocą sesji.

Ten mechanizm ma jednak swoje wady. Największą jest złożoność jaką wprowadza po stronie skryptów na serwerze. (I to nie jest wcale taka trywialna sprawa jak to można było zaobserwować u developerów frameworka CherryPy którzy miesiącami nie potrafili napisać stabilnie działającego mechanizmu obsługi sesji.)

Kontynuacje

Kompletnie innym podejściem jest skorzystanie z tzw. mechanizmu kontynuacji. Mechanizm ten podobny jest do gracza, który w dowolnym momencie może zapisać i wczytać stan gry. Kontynuacje zapewniają taki mechanizm zapisu stanu programu aby w dowolnym momencie później go przywrócić. Niektórzy porównują to do maszyny czasu, bo można w dowolnym momencie przywrócić wcześniejszy stan aplikacji.

Zalet z takiego podejścia jest wiele. Weźmy np. sprawę obsługi “nieśmiertelnego” przycisku Back w przeglądarce. Obsługa tego przycisku sprawia spore problemy. Programiści najchętniej w ogóle by go zablokowali. W wypadku kontynuacji ten problem w ogóle nie istnieje. Kliknął ktoś Back aby cofnąć się do poprzedniej strony? Żaden problem. Serwer przywróci cały wcześniejszy stan aplikacji bez żadnego problemu. I to w sposób przezroczysty dla programisty! Programowanie stron webowych staje się znacznie prostsze, niczym tworzenie aplikacji desktopowej włącznie z debugowaniem krok po kroku. Wg różnych prognoz, tak będziemy programować serwisy internetowe za kilka lat!

Sama idea nie jest najwyraźniej jeszcze powszechnie znana, skoro w rozmowie z developerami irlandzkiego Google, zaskoczyłem ich informacją na ten temat. Kto wie, czy Google mocniej nie zainwestuje w Rubiego (aktualnie mocno korzysta z Pythona, który jest podstawą większości ich skryptów).

Smalltalk i Seaside

Smalltalk jest bardzo starym językiem bo jego początki sięgają lat 70-tych. Od zawsze był językiem w pełni obiektowym i dynamicznym. To m.in. Smalltalk pierwszy wymyślił wirtualną maszynę której to ideę później skopiowali twórcy Javy. W Smalltalku napisano najlepszy (w chwili obecnej) na świecie serwer kontynuacyjny – Seaside.

Czy to spowoduje renesans na Smalltalka? Osobiście w to wątpię. Główną wadą Smalltalka jest jego monolityczność i hermentyczność. Uruchamiając środowisko Smalltalak uruchamia się cały, zamknięty świat Smalltalka. Np. nie ma tam dostępu do plików z zewnątrz tak, jak w innych językach. To spowodowało, że język ten, mimo pewnych sukcesów, nigdy nie zdobył sobie powszechnego uznania. I moim zdanie, nigdy już nie zdobędzie, bo w międzyczasie wyrosła mu młoda, obiecująca konkurencja.

Ruby

Ruby jest językiem relatywnie młodym. Tzn. został po raz pierwszy udostępniony publicznie w tym samym roku co Java – 1995. Ale przez większość lat był mało znany poza Japonią (skąd pochodzi jego twórca). Ruby jest także jednym z tych nielicznych języków, które (podobnie jak Smalltalk) posiadają wbudowaną obsługę kontynuacji. Istnieją co prawda różne próby implementacji tego mechanizmu w Javie¹, ale tylko Ruby posiada ten mechanizm jako coś naturalnego i nie trzeba stosować żadnych specjalnych sztuczek aby go emulować. Z tego co pamiętam, Seaside pierwotnie był tworzony w Ruby, ale w tamtym okresie, kontynuacje w Ruby były jeszcze niedojrzałe, więc twórcy przerzucili się na Smalltalka. Ruby jednak szybko się rozwija, nabiera dojrzałości i moim zdaniem, ma bardzo duże szanse, aby wyprzedzić pozostałe języki przy tworzeniu serwisów internetowych nowej generacji, serwisów opartych na kontynuacjach.

Przykład kontynuacji.

Poniższy przykład² pokazuje implementację generatora za pomocą kontynuacji.

class Generator

  def initialize
    do_generation
  end

  def next
    callcc do |here|
      @main_context = here;
       @generator_context.call
    end
  end

   private

   def do_generation
     callcc do |context|
       @generator_context = context;
       return
     end
     generating_loop
   end

   def generate(value)
     callcc do |context|
       @generator_context = context;
       @main_context.call(value)
     end
   end
end

A oto oparty na nim generator ciągu liczb Fibbonacciego:

class FibGenerator < Generator
  def generating_loop
    generate(1)
    a, b = 1, 1
    loop do
      generate(b)
      a, b = b, a+b
    end
  end
end

fib = FibGenerator.new
15.times { print "#{fib.next} " }
#wynik: 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610

¹ Np. Riff lub Jetty 6.

² Przykład z książki “The Ruby Way”, 1ed.

Sun zatrudnił programistów JRuby

Jarosław Zabiełło — Fri, 08 Sep 2006 10:33:00 +0200

W środowisku javowców Ruby jest językiem który robi trochę zamieszania (jakoś tak się składa, że Ruby bardziej przemawia do programistów Javy niż Python). Cieszy zatem, że firma Sun podjęła decyzję o wsparciu projektu JRuby zatrudniając jego czołowych developerów. Powinno to znacznie przyśpieszyć prace nad tym projektem podobnie jak stało się z IronPythonem, gdy Microsoft zatrudnił jego twórcę.

Jestem ciekaw jak długo programiści zachowają entuzjazm dla swego języka, gdy będzie można generować taki sam bytecode Javy lecz w niezrównanie prostszy sposób. :)

Przykładowy kod Javy:

public class Filter {
  public static void main(String[] args) {
    List list = new java.util.ArrayList();
    list.add("Tim"); list.add("Ike"); list.add("Tina");
    Filter filter = new Filter();
    for (String item : filter.filterLongerThan(list, 3)) { 
      System.out.println( item ); 
    }
  }
  public List filterLongerThan(List list, int length) {
    List result = new ArrayList();
    for (String item : list) {
      if (item.length() <= length) { result.add( item ); }
    }
    return result;
  }
}

A oto odpowiadający mu kod w Ruby:

list = ['Tim', 'Ike', 'Tina']
list.select {|n| n.length > 3}.each {|n| puts n}

Oczywiście to nie wszystko. Dzięki JRuby można uzyskać efekty kompletnie nieosiągalne w standardowej Javie – np. można pracować z biblioteką Swing w sposób interaktywny, z poziomu interpretera zmieniając na żywo jej obiekty.

Wkrótce ma także być gotowa wersja Railsów działająca z JRuby (Zobacz prezentację w PowerPoint). Tym samym odeszłyby wszelkie uwagi co do wydajności Railsów, bo współczesna wirtualna maszyna Javy jest tak silnie zoptymalizowna że dorównuje językowi C++. Oczywiście model wątkowy JRuby jest zgodny z wydajnym i dojrzałym modelem wątkowym Javy – po prostu z niego korzysta.

Akcesory w Javie, Pythonie, Ruby i PHP5

Jarosław Zabiełło — Tue, 07 Feb 2006 23:25:00 +0100

Java, język który dobył sobie silną pozycję na rynku korporacyjnym, jest od jakiegoś czasu pod obstrzałem krytyki z różnych stron. Wyszła cała seria książek krytykujących model obiektowy oraz metodologie promowane przez Javę (od najsłynniejszej Beyond Java po Bitter Java, Bitter EJB, czy inne)

Nie umniejszając zalet Javy, jej krytycy wytykają jej niepotrzebną nadmiarowość kodu, ociężałość i małą zwrotność, która powoduje że język ten słabo nadaje się do modnej ostatnio metodologii _agile programming. _ Aby lepiej ten problem zobaczyć, przyjrzyjmy się typowej praktyce programistów Javy. Tekst ten zainspirowany jest niedawną dyskusją jaka miała miejsce w jednym z blogów mojego kolegi.

Czym są akcesory?

Akcesory (lub inaczej: gettery i settery) to slangowe okreslenie metod jakie używa obiekt do odczytu i modyfikacji swoich atrybutów. Są one tak nagminnie używane przez programistów Javy, że niektóre edytory (np. Eclipse) zostały nawet wyposażone w makra do automatycznego ich generowania.

Dorzucanie nieużywanego kodu “na wszelki wypadek”...

Nagminna (wśród programistów Javy) praktyka dodawania akcesorów do atrybutów klasy pachnie jakimś antipatternem i są głosy, które używanie akcesorów nazwyają wprost złą praktyką . Jest w tym trochę racji. Ale, jak to poniżej wykażę, jest to pewnego rodzaju kompromis w związku ze słabym modelem obiektowy Javy.

Dlaczego programiści Javy generują akcesory dla każdego atrybutu nawet, jak nie przewidują potrzeby ich używania? Otóż czynią to “na wszelki wypadek” bo nie wiedzą, czy w przyszłości nie będzie im to potrzebne…

Weźmy np. taki kod (z powodu kolejnego ograniczenia Javy nie można w jednym pliku trzymać więcej, niż jednej klasy; tu dla krótkości umieszczam kod z obu plików razem)

public class First {
  public String msg = "hello";
}

public class Second extends First {
  public static void main(String[] args) {
    First obj = new First();        
    System.out.println(obj.msg);
  }
}

Jak widać, w Javie można sięgać do atrybutu w sposób bezpośredni.

Wyobraźmy sobie jednak, że projekt nam się rozrósł i mamy już całkiem sporo kodu oraz sporo plików (pomnażanych wydatnie przez javowe ograniczenia co do ilości klas mogących wystąpić w pliku). Teraz przychodzi polecenie aby w momencie odczytu i zapisu atrybutu coś dodatkowego wykonać. (Np. niech to będzie logowanie informacji o takim zdarzeniu, albo zablokowanie możliwości modyfikacji treści atrybutu. Wszystko jedno co)

Mamy zatem pierwszy problem. Trzeba w tych wszystkich milionach miejsc, gdzie odwoływaliśmy się bezpośrednio do atrybutów, wymienić kod…

Właśnie dlatego, aby takich niespodzianek uniknąć w przyszłości, programiści Javy dorzucają dodatkowe metody opakowujące odczyt i zapis atrybutów. Eclipse upraszcza ten proces zwalniając programistę od ręcznego wpisywania tego kodu.

Klasa First po zmianie:

public class First {
  public String msg = "hello";
  public String getMsg() {
    return msg;
  }
  public void setMsg(String msg) {
    this.msg = msg;
  }
}

Wydaje się, że problem jest rozwiązany. Ale to dopiero początek innych problemów.

Jeśli bowiem, automatycznie dorzucamy te metody do wszystkich tysięcy atrybutów nowo tworzonych klas, to pierwszą rzeczą którą zauważamy, jest nagłe “spuchnięcie kodu”. Mamy kupę nieużywanych linii kodu, z których prawdopodobnie większość nie będzie nigdy używana!

Ale to nie wszystko. Załóżmy, że stajemy przed potrzebą zmiany nazwy atrybutu. Oczywiście, możemy to zmienić w jednym miejscu (w ciele akcesora), ale wtedy wprowadzamy chaos w pozostałej części odnośnie… nazw (atrybut “msg” zmieniony na “title” trochę głupio wygląda z akcesorami o nazwie “getMsg” i “setMsg”) Musimy przekopać się przez miliony miejsc w kodzie i pozmieniać nazwy starym wywołaniom.

Zobaczmy jak ta sytuacja wygląda w językach dynamicznych.

Python

Python (podobnie jak Java) pozwala na bezpośredni dostęp do atrybutów klasy. A co w sytuacji kiedy chcemy opakować atrybut akcesorami? Nic prostszego. Python pozwala na dodanie akcesorów wtedy, i tylko wtedy, kiedy są potrzebne. Na dodatek czyni to w sposób całkowicie przezroczysty dla pozostałej części kodu. Programista Javy może sobie o tym tylko pomarzyć.

class X(object):
  def get_msg(self):
    return self.__msg
  def set_msg(self, val):
    self.__msg = val
  msg = property(get_msg, set_msg)

obj = X()
obj.msg = "hello"
print obj.msg

Python pozwala także związać z dowolną metodą, atrybutem, klasą czy modułem docstring, czyli tekst z dokumentacją, objaśnieniem itp. To jedna z genialnych cech Pythona specjalnie pomyślana dla leniwych programistów, którym nie chce się pisać dokumentacji. ;)

Ruby

W języku Ruby z definicji nie ma żadnej możliwości dostępu do atrubutów klasy inaczej jak przez akcesory. Odpada więc problem zapominania aby je dodać. Ruby jednak narzuca nazwy dla akcesorów (mają nazwę taką jak atrybut!) i całość wygląda tak, jakby operowano bezpośrednio na atrybucie.

class X
  def msg
    @msg
  end
  def msg=(val)
    @msg = val
  end
end

obj = X.new
obj.msg = "hello"
puts obj.msg

Dla osób, które nie lubią za dużo pisać, Ruby ma wygodne skróty. Powyższą definicję klasy można zapisać także w ten sposób:

class X
  attr_accessor :msg
end

Istnieją także oddzielne skróty dla getterów i setterów. No i można po przecinku dodać akcesory dla całej grupy atrybutów.

PHP5

PHP w wersji 5 ma przebudowany model obiektowy od podstaw. Twórcy języka PHP nie starali się poprawiać modelu obiektowego PHP4 (był on tak zły, że prościej było im napisać go od nowa). W nowym PHP5 mamy już możliwość przezroczystego dodania akcesora.

<?php
class X {
  private $attributes = array('msg'=>null);
  private function __get($attrname) {
    return $this->attributes[$attrname];
  }
  private function __set($attrname, $val) {
    $this->attributes[$attrname] = $val;
  }
}

$obj = new X();
$obj->msg = "hello";
print $obj->msg;
?>

Składnia może nie jest tak prosta jak w Ruby, ale (przynajmniej w tym miejscu), PHP5 zachowuje się tu sensownie i unika dylematów Javy.