Panos Louridas

The bug catalog of the maven ecosystem

Examining software ecosystems can provide the research community with data regarding artifacts, processes, and communities. We present a dataset obtained from the Maven central repository ecosystem (approximately 265GB of data) by statically analyzing the repository to detect potential software bugs. For our analysis we used FindBugs, a tool that examines Java bytecode to detect numerous types of bugs. The dataset contains the metrics results that FindBugs reports for every project version (a JAR) included in the ecosystem. For every version we also stored specific metadata such as the JARs size, its dependencies and others. Our dataset can be used to produce interesting research results, as we show in specific examples.

Embedded Analytics and Statistics for Big Data

Embedded analytics and statistics for big data have emerged as an important topic across industries. As the volumes of data have increased, software engineers are called to support data analysis and applying some kind of statistics to them. This article provides an overview of tools and libraries for embedded data analytics and statistics, both stand-alone software packages and programming languages with statistical capabilities.

The Carbon Footprint of Conference Papers.

The action required to stem the environmental and social implications of climate change depends crucially on how humankind shapes technology, economy, lifestyle and policy. With transport CO2 emissions accounting for about a quarter of the total, we examine the contribution of CO2 output by scientific travel. Thankfully for the reputation of the scientific community, CO2 emissions associated with the trips required to present a paper at a scientific conference account for just 0.003% of the yearly total. However, with CO2 emissions for a single conference trip amounting to 7% of an average individual’s total CO2 emissions, scientists should lead by example by demonstrating leadership in addressing the issue.

A note on rigour and replicability

As any empirical science, Software Engineering research should strive towards better research practices. Replication is regrettably not a priority for Software Engineering researchers and, moreover, not afforded by many published studies. Here we report our experience from our encounter with a recent paper in a agship Software Engineering conference. Our experience shows that current publication requirements do not guarantee replicability.

The evolution of C programming practices: a study of the Unix operating system 1973--2015

Tracking long-term progress in engineering and applied science allows us to take stock of things we have achieved, appreciate the factors that led to them, and set realistic goals for where we want to go. We formulate seven hypotheses associated with the long term evolution of C programming in the Unix operating system, and examine them by extracting, aggregating, and synthesising metrics from 66 snapshots obtained from a synthetic software configuration management repository covering a period of four decades. We found that over the years developers of the Unix operating system appear to have evolved their coding style in tandem with advancements in hardware technology, promoted modularity to tame rising complexity, adopted valuable new language features, allowed compilers to allocate registers on their behalf, and reached broad agreement regarding code formatting. The progress we have observed appears to be slowing or even reversing prompting the need for new sources of innovation to be discovered and followed.

When students are not programmers

We present our experience from using Python to teach programming to high school students (aged 15). We selected Python as it is regarded to be a language suitable for teaching, while at the same time it has the advantage of being a production language, widely used around the world. Our experience shows that the success of a language in a professional setting does not predict success as a teaching tool. Based on our observations we offer some general conclusions on programming languages for teaching.

Relational access to Unix kernel data structures

State of the art kernel diagnostic tools like DTrace and Systemtap provide a procedural interface for expressing analysis tasks. We argue that a relational interface to kernel data structures can offer complementary benefits for kernel diagnostics. This work contributes a method and an implementation for mapping a kernels data structures to a relational interface. The Pico COllections Query Library (PiCO QL) Linux kernel module uses a domain specific language to define a relational representation of accessible Linux kernel data structures, a parser to analyze the definitions, and a compiler to implement an SQL interface to the data structures. It then evaluates queries written in SQL against the kernels data structures. PiCO QL queries are interactive and type safe. Unlike SystemTap and DTrace, PiCO QL is less intrusive because it does not require kernel instrumentation; instead it hooks to existing kernel data structures through the modules source code. PiCO QL imposes no overhead when idle and needs only access to the kernel data structures that contain relevant information for answering the input queries. We demonstrate PiCO QLs usefulness by presenting Linux kernel queries that provide meaningful custom views of system resources and pinpoint issues, such as security vulnerabilities and performance problems.

Generating the blueprints of the Java ecosystem

Examining a large number of software artifacts can provide the research community with data regarding quality and design. We present a dataset obtained by statically analyzing 22730 jar files taken from the Maven central archive, which is the de-facto application library repository for the Java ecosystem. For our analysis we used three popular static analysis tools that calculate metrics regarding object-oriented design, program size, and package design. The dataset contains the metrics results that every tool reports for every selected jar of the ecosystem. Our dataset can be used to produce interesting research results, such as measure the domain-specific language usage.

Comparative language fuzz testing: programming languages vs. fat fingers

We explore how programs written in ten popular programming languages are affected by small changes of their source code. This allows us to analyze the extend to which these languages allow the detection of simple errors at compile or at run time. Our study is based on a diverse corpus of programs written in several programming languages systematically perturbed using a mutation-based fuzz generator. The results we obtained prove that languages with weak type systems are significantly likelier than languages that enforce strong typing to let fuzzed programs compile and run, and, in the end, produce erroneous results. More importantly, our study also demonstrates the potential of comparative language fuzz testing for evaluating programming language designs.

What are your programming language's energy-delay implications?

Motivation: Even though many studies examine the energy efficiency of hardware and embedded systems, those that investigate the energy consumption of software applications are still limited, and mostly focused on mobile applications. As modern applications become even more complex and heterogeneous a need arises for methods that can accurately assess their energy consumption. Goal: Measure the energy consumption and run-time performance of commonly used programming tasks implemented in different programming languages and executed on a variety of platforms to help developers to choose appropriate implementation platforms. Method: Obtain measurements to calculate the Energy Delay Prod- uct, a weighted function that takes into account a tasks energy consumption and run-time performance. We perform our tests by calculating the Energy Delay Product of 25 programming tasks, found in the Rosetta Code Repository, which are implemented in 14 programming languages and run on three different computer platforms, a server, a laptop, and an embedded system. Results: Compiled programming languages are outperforming the interpreted ones for most, but not for all tasks. C, C#, and JavaScript are on average the best performing compiled, semi-compiled, and interpreted programming languages for the Energy Delay Product, and Rust appears to be well-placed for i/o-intensive operations, such as file handling. We also find that a good behaviour, energy- wise, can be the result of clever optimizations and design choices in seemingly unexpected programming languages.