What Java Developers Know About Compatibility, And Why This Matters

Real-world programs are neither monolithic nor static -- they are constructed using platform and third party libraries, and both programs and libraries continuously evolve in response to change pressure. In case of the Java language, rules defined in the Java Language and Java Virtual Machine Specifications define when library evolution is safe. These rules distinguish between three types of compatibility - binary, source and behavioural. We claim that some of these rules are counter intuitive and not well-understood by many developers. We present the results of a survey where we quizzed developers about their understanding of the various types of compatibility. 414 developers responded to our survey. We find that while most programmers are familiar with the rules of source compatibility, they generally lack knowledge about the rules of binary and behavioural compatibility. This can be problematic when organisations switch from integration builds to technologies that require dynamic linking, such as OSGi. We have assessed the gravity of the problem by studying how often linkage-related problems are referenced in issue tracking systems, and find that they are common

HepData reloaded: reinventing the HEP data archive

We describe the status of the HepData database system, following a major re-development in time for the advent of LHC data. The new HepData system benefits from use of modern database and programming language technologies, as well as a variety of high-quality tools for interfacing the data sources and their presentation, primarily via the Web. The new back-end provides much more flexible and semantic data representations than before, on which new external applications can be built to respond to the data demands of the LHC experimental era. The HepData re-development was largely motivated by a desire to have a single source of reference data for Monte Carlo validation and tuning tools, whose status and connection to HepData we also briefly review.Comment: 7 pages, 3 figures, Presented at 13th International Workshop on Advanced Computing and Analysis Techniques in Physics Research (ACAT 2010), February 22-27, 2010, Jaipur, Indi

UT Digital Repository: 08-09 Annual Report

UT Librarie

Web based system architecture for long pulse remote experimentation

Remote experimentation (RE) methods will be essential in next generation fusion devices. Requirements for long pulse RE will be: on-line data visualization, on-line data acquisition processes monitoring and on-line data acquisition systems interactions (start, stop or set-up modifications). Note that these methods are not oriented to real-time control of fusion plant devices. INDRA Sistemas S.A., CIEMAT (Centro de Investigaciones Energéticas Medioambientales y Tecnológicas) and UPM (Universidad Politécnica de Madrid) have designed a specific software architecture for these purposes. The architecture can be supported on the BeansNet platform, whose integration with an application server provides an adequate solution to the requirements. BeansNet is a JINI based framework developed by INDRA, which makes easy the implementation of a remote experimentation model based on a Service Oriented Architecture. The new software architecture has been designed on the basis of the experience acquired in the development of an upgrade of the TJ-II remote experimentation system

Putting the Semantics into Semantic Versioning

The long-standing aspiration for software reuse has made astonishing strides in the past few years. Many modern software development ecosystems now come with rich sets of publicly-available components contributed by the community. Downstream developers can leverage these upstream components, boosting their productivity. However, components evolve at their own pace. This imposes obligations on and yields benefits for downstream developers, especially since changes can be breaking, requiring additional downstream work to adapt to. Upgrading too late leaves downstream vulnerable to security issues and missing out on useful improvements; upgrading too early results in excess work. Semantic versioning has been proposed as an elegant mechanism to communicate levels of compatibility, enabling downstream developers to automate dependency upgrades. While it is questionable whether a version number can adequately characterize version compatibility in general, we argue that developers would greatly benefit from tools such as semantic version calculators to help them upgrade safely. The time is now for the research community to develop such tools: large component ecosystems exist and are accessible, component interactions have become observable through automated builds, and recent advances in program analysis make the development of relevant tools feasible. In particular, contracts (both traditional and lightweight) are a promising input to semantic versioning calculators, which can suggest whether an upgrade is likely to be safe.Comment: to be published as Onward! Essays 202

Vulnerable Open Source Dependencies: Counting Those That Matter

BACKGROUND: Vulnerable dependencies are a known problem in today's open-source software ecosystems because OSS libraries are highly interconnected and developers do not always update their dependencies. AIMS: In this paper we aim to present a precise methodology, that combines the code-based analysis of patches with information on build, test, update dates, and group extracted from the very code repository, and therefore, caters to the needs of industrial practice for correct allocation of development and audit resources. METHOD: To understand the industrial impact of the proposed methodology, we considered the 200 most popular OSS Java libraries used by SAP in its own software. Our analysis included 10905 distinct GAVs (group, artifact, version) when considering all the library versions. RESULTS: We found that about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice. Developers of the analyzed libraries are able to fix (and actually responsible for) 82% of the deployed vulnerable dependencies. The vast majority (81%) of vulnerable dependencies may be fixed by simply updating to a new version, while 1% of the vulnerable dependencies in our sample are halted, and therefore, potentially require a costly mitigation strategy. CONCLUSIONS: Our case study shows that the correct counting allows software development companies to receive actionable information about their library dependencies, and therefore, correctly allocate costly development and audit resources, which is spent inefficiently in case of distorted measurements.Comment: This is a pre-print of the paper that appears, with the same title, in the proceedings of the 12th International Symposium on Empirical Software Engineering and Measurement, 201

Setup and configuration of a digital library based on Ubuntu and DSpace

The purpose of this project is to analyze the requirements, prepare the technologic environment and perform the deployment of a Digital Repository to improve the information processes of an organization.García Martínez, JV. (2012). Setup and configuration of a digital library based on Ubuntu and DSpace. http://hdl.handle.net/10251/17657.Archivo delegad