Transcript Stack-Based Query Language for Java

Plan prezentacji
 Motywacje powstania
 Cele projektu
 Podstawowe założenia
 Niezgodność impedancji
 Integracja składniowa
 Architektura rozwiązania
 Plany rozwoju projektu
 Podsumowanie
2
PJWSTK 2010
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 ;-)
3
PJWSTK 2010
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
4
PJWSTK 2010
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
5
PJWSTK 2010
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
6
PJWSTK 2010
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
7
PJWSTK 2010
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”
8
PJWSTK 2010
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 i where i > 7 };
System.out.println(result);
• Całe zapytanie jako nowy element składniowy
• Minimalna ilość nowych połączeń
• Zapytanie jako wywołanie funkcji
9
PJWSTK 2010
Architektura rozwiązania
 Dodatkowa faza preprocesingu
Kod źródłowy
zapytań
Wygenerowany
kod Java
*.s4j
*.s4j
*.s4j
*.s4j
*.java
*.s4j
preprocesing
10
PJWSTK 2010
Skompilowany
kod
*.s4j
*.s4j
*.class
kompilacja
uruchomienie
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
11
PJWSTK 2010
Faza preprocesingu cd.
Kod źródłowy i biblioteki
Preprocesor SBQL4J
Java Parser
*.java
*.jar
12
Wygenerowany kod źródłowy
Java Analyser
*.s4j
*.class
PJWSTK 2010
SBQL4J
Parser
SBQL4J
Analyser
Code
generator
*.java
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
13
PJWSTK 2010
Przegląd sygnatur
 ValueSignature
 BinderSignature
 ClassSignature
 MethodSignature
 ConstructorSignature
 StructSignature
 PackageSignature
14
PJWSTK 2010
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
15
PJWSTK 2010
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ą
16
PJWSTK 2010
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ń
17
PJWSTK 2010
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ść
18
PJWSTK 2010
Generowany kod interpretera bez
stosu QRES
 Wyniki podzapytań jako nowe zmienne w kodzie
 Generowanie unikalnych nazw podzapytań
 Minimalna ilość koercji w trakcie wykonania
19
PJWSTK 2010
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
20
PJWSTK 2010
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();
Comparator plCollator = ...; //porównywanie polskich liter
List<Product> orderedProducts = #{
products order by
unitsInStock desc;
productName asc using plCollator
};
21
PJWSTK 2010
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)
};
22
PJWSTK 2010
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
DBLink warehouseDBLink = ...;
List<String> result =
#{ warehouseDBLink.((cusomers rollby segment).name) };
System.out.println(result);
23
PJWSTK 2010
Plany rozwoju projektu cd.
 Optymalizacja zapytań przez przepisywanie
 Zintegrowane środowisko programistyczne (IDE) dla
SBQL4J
 Zapytania ad-hoc i kontrola typologiczna w czasie
wykonania
24
PJWSTK 2010
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
25
PJWSTK 2010
Dziękuję za uwagę
26
PJWSTK 2010