Queryll: Java Database Queries through Bytecode Rewriting

When interfacing Java with other systems such as databases, programmers must often program in special interface languages like SQL. Code written in these languages often needs to be embedded in strings where they cannot be error-checked at compile-time, or the Java compiler needs to be altered to directly recognize code written in these languages. We have taken a different approach to adding database query facilities to Java. Bytecode rewriting allows us to add query facilities to Java whose correctness can be checked at compile-time but which don't require any changes to the Java language, Java compilers, Java VMs, or IDEs. Like traditional object-relational mapping tools, we provide Java libraries for accessing individual database entries as objects and navigating among them. To express a query though, a programmer simply writes code that takes a Collection representing the entire contents of a database, iterates over each entry like they would with a normal Collection, and choose the entries of interest. The query is fully valid Java code that, if executed, will read through an entire database and copy entries into Java objects where they will be inspected. Executing queries in this way is obviously inefficient, but we have a special bytecode rewriting tool that can decompile Java class files, identify queries in the bytecode, and rewrite the code to use SQL instead. The rewritten bytecode can then be run using any standard Java VM. Since queries use standard Java set manipulation syntax, Java programmers do not need to learn any new syntax. Our system is able to handle complex queries that make use of all the basic relational operations and exhibits performance comparable to that of hand-written SQL

An Aspect Pointcut for Parallelizable Loops

This study investigated the need for a pointcut for parallelizable loops in an aspect-oriented programming environment. Several prototype solutions exist for loop pointcuts, but the solutions are not very granular. In particular, they are not able to differentiate between loops that are parallelizable and those that are not. Being able to identify parallelizable loops automatically, as part of an aspect-oriented compiler\u27s weaving process, is particularly important because (1) manually identifying parallelizable loops is known to be a difficult problem and (2) aspectizing parallelized loops can lead to a reduction in code tangling and an increase in separation of concerns. This paper describes the concepts behind the loop-pointcut problem. It then describes the approach used in this study for implementing a solution in the form of an aspect-oriented Java compiler with a parallelizable loop pointcut. Identifying parallelizable loops is known to be a difficult problem, and as such, this study\u27s parallelizable loop pointcut implements a heuristic solution. The pointcut identifies many parallelizable loops as being parallelizable, but in erring on the side of conservatism, there are some parallelizable loops that the pointcut is unable to identify as parallelizable. To test the parallelizable-loop pointcut, the pointcut was applied to a benchmark set of parallelizable programs. There were two versions of each benchmark program - (1) an aspect-oriented version, where the aspect-oriented compiler\u27s weaver added the multi-threading functionality, and (2) a non-aspect-oriented version, where the benchmark program\u27s source code directly implemented the multi-threading functionality. For each benchmark program, the output from the aspect-oriented version was compared to the output from the non-aspect-oriented version. The study found that each loop that was deemed parallelizable by the aspect-oriented benchmark program was executed in parallel (with multiple threads) by both versions of the program - the aspect-oriented version and the non-aspect-oriented version. There were some loops in the non-aspect-oriented benchmark programs that were deemed parallelizable and executed in parallel, but those same loops were deemed non-parallelizable by their associated aspect-oriented benchmark program. This discrepancy is explained by the study\u27s conservative approach to identifying loops as parallelizable