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

Motywacje powstania PJWSTK 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 ;-)

Cele projektu PJWSTK 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

Podstawowe problemy PJWSTK 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

Niezgodność impedancji cd. PJWSTK 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

Niezgodność impedancji cd. 2 PJWSTK 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 Konieczne określenie typu elementow kolekcji

Zasada korespondencji PJWSTK 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”

Integracja składniowa PJWSTK 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 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

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

Faza preprocesingu PJWSTK 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

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

Sygnatury zapytań PJWSTK 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

Przegląd sygnatur PJWSTK ValueSignature BinderSignature ClassSignature MethodSignature ConstructorSignature StructSignature PackageSignature

Kontrola błędów PJWSTK 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

Translacja zapytań na kod Java PJWSTK 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ą

Tryb interpretera PJWSTK 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ń

Generowany kod interpretera PJWSTK 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ść

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

Generowany kod bez stosów QRES i ENVS PJWSTK 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

Nowy operator order by PJWSTK Funkcja sortująca zdefiniowana zgodnie ze standardami Javy: W obiekcie sortowanym – interfejs java.lang.Comparable W obiekcie implementującym java.util.Comparator List products = getProductList(); Comparator plCollator =...; //porównywanie polskich liter List orderedProducts = #{ products order by unitsInStock desc; productName asc using plCollator };

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

Plany rozwoju projektu PJWSTK 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 result = #{ warehouseDBLink.((cusomers rollby segment).name) }; System.out.println(result);

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

Podsumowanie PJWSTK 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

Dziękuję za uwagę PJWSTK