Stack-Based Query Language for Java

1. Stack-BasedQueryLanguagefor Java Język zapytań oparty na podejściu stosowym zintegrowany z Javą Emil Wcisło

2. Plan prezentacji • Motywacje powstania • Cele projektu • Podstawowe założenia • Niezgodność impedancji • Integracja składniowa • Architektura rozwiązania • Plany rozwoju projektu • Podsumowanie PJWSTK 2010

3. Motywacje powstania • Większa moc języka Java • Lepsza pielęgnacyjność kodu • Synergia Java + język zapytań • Nowe cechy SBQL • „Marketing” podejścia stosowego • Odpowiedź na LINQ • Podstawa mocnego API do baz danych • Chęć obrony mgr ;-) PJWSTK 2010

4. Cele projektu • Zapytania na obiektach Java • Zachowanie cech SBQL • Integracja składniowa • Mocna kontrola typów w czasie kompilacji • Kompatybilność wsteczna • Możliwość wywołania metod i konstruktorów z zapytań • Wydajność – tłumaczenie zapytań na kod Javy PJWSTK 2010

5. Podstawowe problemy • Niezgodność impedancji • Składnia - różne style i budowa programów • Rozwiązanie – dopasowanie składni operatorów mających odpowiedniki w języku programowania (np. ==, !=, !, &&, ||, new, instanceof) • Nowe operatory (np. where, join, order by) – wartość dodana języka • Systemy typów • Jednolity model danych • SBA – wyższy poziom abstrakcji PJWSTK 2010

6. Niezgodność impedancji cd. • Semantyka i paradygmaty programów – deklaratywność kontra imperatywność • Zapytania jako specjalne wyrażenia (wywołanie funkcji) • Generowanie funkcji realizującej zapytanie • Poziomy abstrakcji – wysoki języka zapytań, niski języka programowania • Integracja dwukierunkowa • Generyczność operatorów – wykorzystanie standardowych interfejsów (operatory ==, porównania zakresowego, order by) • Możliwość użycia metod, funkcji i konstruktorów Java PJWSTK 2010

7. Niezgodność impedancji cd. 2 • Przetwarzanie kolekcji • Specjalne traktowanie obiektów kolekcji w języku zapytań • Mapowanie java.util.Collection <-> bag, java.util.List <-> sequence • Kolekcje generyczne w języku zapytań, np. bag<HashSet> • Konieczne określenie typu elementow kolekcji PJWSTK 2010

8. Zasada korespondencji • Język zapytań – ok. 35 operatorów • Java – ok. 240 nie-terminali • Bezpośrednie włączenie zapytań oznacza potencjalnie ponad 8400 punktów styku Oznacza to: • Trudności w rozwoju języka zapytań • Konflikty dla operatorów o tej samej składni i różnej semantyce • Ogólne zagmatwanie ostatecznego „tworu” PJWSTK 2010

9. Integracja składniowa Rozwiązanie problemu korespondencji – rozdzielenie składni na rozłączne konteksty Integer[] n = new Integer[] {4, 2, 6, 20, 4, 23, 1, 5, 7}; List<Integer> result =#{ n as iwhere i > 7 }; System.out.println(result); • Całe zapytanie jako nowy element składniowy • Minimalna ilość nowych połączeń • Zapytanie jako wywołanie funkcji PJWSTK 2010

10. *.s4j *.s4j *.s4j *.s4j *.class *.java Architektura rozwiązania • Dodatkowa faza preprocesingu Kod źródłowy zapytań Wygenerowany kod Java Skompilowany kod *.s4j *.s4j *.s4j preprocesing kompilacja uruchomienie PJWSTK 2010

11. Faza preprocesingu Zadania: • Parsowanie i analiza zapytań • Analiza użytych bytów Java (min. zmienne, klasy, metody) • Analiza kodu Javy • Translacja zapytań na kod Javy Środki: • Integracja z kompilatorem Java (OpenJDK) • Typechecker i sygnatury zapytań • Generator kodu Java PJWSTK 2010

12. Wygenerowany kod źródłowy Kod źródłowy i biblioteki *.java *.s4j *.java *.jar *.class Faza preprocesingucd. Preprocesor SBQL4J Java Parser Java Analyser Code generator SBQL4J Parser • SBQL4J Analyser PJWSTK 2010

13. Sygnatury zapytań • Są tworzone w trakcie analizy • Zawierają informacje o wyniku zapytania lub podzapytania • Liczność wyniku ([0..1] lub [0..*] dla kolekcji) • Typ kolekcji wynikowej (bag, sequence) • Nazwa typu • Inne właściwości charakterystyczne dla danego typu sygnatury • Podobnie jak obiekty w runtime, zawierają metodę nested PJWSTK 2010

14. Przegląd sygnatur • ValueSignature • BinderSignature • ClassSignature • MethodSignature • ConstructorSignature • StructSignature • PackageSignature PJWSTK 2010

15. Kontrola błędów • Zgłoszenia za pomocą standardowego mechanizmu kompilatora Javy • W przypadku błędu zgłoszenie, wstawienie domyślnej sygnatury dla danego operatora i kontynuacja • Każdy operator wymaga określonej sygnatury o odpowiednich atrybutach (np. typ wyniku, liczność) • Sprawdzane są błędy zarówno w zapytaniach, jak i w kodzie Java PJWSTK 2010

16. Translacja zapytań na kod Java Dostępne 4 tryby translacji: • Wywołanie interpretera • Generacja kodu tożsamego z interpreterem • Zoptymalizowany kod interpretera bez stosu QRES • Natywne operacje Java bez stosów QRES i ENVS Balansowanie między elastycznością i wydajnością PJWSTK 2010

17. Tryb interpretera • Klasa implementująca wzorzec Visitor • Tekst zapytania parsowany w runtime programu • Przekazanie parametrów z kontekstu Java na spód stosu ENVS • Obiekty Java otoczone wrapperami w trakcie wykonania • Niska wydajność, duża elastyczność – możliwe dynamiczne tworzenie zapytań PJWSTK 2010

18. Generowany kod interpretera • Zapytanie jako metoda wygenerowanej klasy • Kod zapytania tożsamy z ścieżką wywołania interpretera • Stosy QRES i ENVS używane w trakcie wykonania • Tylko zapytania zdefiniowane przed kompilacją • Brak parsowania tekstu zapytania i generowania drzewa AST podczas uruchomienia • Wyższa wydajność – mniejsza elastyczność PJWSTK 2010

19. Generowany kod interpretera bez stosu QRES • Wyniki podzapytań jako nowe zmienne w kodzie • Generowanie unikalnych nazw podzapytań • Minimalna ilość koercji w trakcie wykonania PJWSTK 2010

20. Generowany kod bez stosów QRES i ENVS • Maksymalne wykorzystanie możliwości maszyny wirtualnej Java • Zamiana nazw użytych w zapytaniu na nazwy z modelu danych • Konieczna dodatkowa analiza wiązania nazw i użycia funkcji nested • Największa wydajność i czytelność wygenerowanego kodu PJWSTK 2010

21. Nowy operator order by • Funkcja sortująca zdefiniowana zgodnie ze standardami Javy: • W obiekcie sortowanym – interfejs java.lang.Comparable • W obiekcie implementującym java.util.Comparator List<Product> products = getProductList(); ComparatorplCollator = ...; //porównywanie polskich liter List<Product> orderedProducts = #{ products order by unitsInStockdesc; productNameascusingplCollator }; PJWSTK 2010

22. Generyczne kolekcje • Rozdzielenie interfejsu (bag, sequence) od implementacji • Specjalizacja kolekcji bez zmian w semantyce języka List<Product> products = getProductList(); Collection<String> orderedProducts = #{ bag<HashSet>(products.productName) }; PJWSTK 2010

23. Plany rozwoju projektu • Uniwersalne API do baz danych i innych źródeł danych • Wariant translacji zapytań SBQL4J na natywne zapytania / operacje uzyskania danych • Wariant podzapytań niezależnych składniowo • „Smart parsing” • Podział na konteksty wewnątrz zapytania • Możliwość rozszerzenia semantyki języka przez dodanie biblioteki • Większe możliwość integracji DBLinkwarehouseDBLink = ...; • List<String> result = • #{warehouseDBLink.((cusomersrollby segment).name) }; System.out.println(result); PJWSTK 2010

24. Plany rozwoju projektu cd. • Optymalizacja zapytań przez przepisywanie • Zintegrowane środowisko programistyczne (IDE) dla SBQL4J • Zapytania ad-hoc i kontrola typologiczna w czasie wykonania PJWSTK 2010

25. Podsumowanie • Mocny język zapytań oparty na SBQL, zintegrowany z Javą • Przełamanie niezgodności impedancji • Niskie ryzyko użycia w istniejących projektach • Szerokie możliwości rozwoju PJWSTK 2010

26. Dziękuję za uwagę PJWSTK 2010