In previous work [ 13, 14 ], we considered 26 Java relational database technologies that o↵er a direct means of accessing a relational database and whose presence in a project is identifiable through static analysis. By analysing the import statements in Java files as well as the presence of specific configuration files, we determined the presence of each of these technologies. We performed a survival analysis of the technologies used in order to determine their relative importance over time in the considered projects.

This paper provides a more in-depth study, by looking at the interaction between object-oriented source code and relational databases at a more fine-grained level. We have selected three popular technologies that are representative of a particular way to connect the source code to a database (embedded SQL, external mapping files, and Java annotations):

jdbc1 is a low-level technology for connecting Java programs to a database by sending SQL queries directly from within the source code. While version 1.1 was released in 1997, there have been regular version upgrades to cope with the evolution of the Java language. This technology is still intensively used in numerous projects [ 13 ], despite the inherently close coupling that is required between the source code and the database schema.

In our study we consider this technology as being associated to a Java source code file if entities belonging to java.sql are imported in this file.

ORM technologies rely on a mapping description for associating (object-oriented) source code elements to database elements. They aim to reduce the so-called object-relational impedance mismatch [ 15 ]. The mapping description can take the form of configuration files, placed aside source code files, to express the relations between the considered entities. Hibernate is a popular open source Java framework adopting this solution. It was first released in 2001, and provides an abstraction layer on top of jdbc. Hibernate has been criticised by many of not being a 100% transparent data persistence solution.

In our study we analyse Hibernate2 XML configuration files (denoted by hbm hereafter), and consider that a Java file relies on Hibernate technology if at least one Hibernate configuration file mentions the Java file as a code entity resource.

JPA Annotation-based mapping descriptions o↵er an increasingly popular means to express the relations required by ORM engines. With such mappings, Java annotations are used to mark program elements as 1oracle.com/technetwork/java/javase/jdbc/ 2hibernate.org/ counterparts of database entities. The Java Persistence API 3 (denoted by jpa hereafter) is the de facto Java standard for annotation-based mappings. jpa was first released in 2006, and relies on the Java annotation mechanism that was first introduced in Java 5. We consider this technology as representative for this kind of mapping description.

In our study we consider that a Java file relates to jpa if the Entity, Embeddable, or MappedSuperclass annotations from package javax.persistence can be found in this file.

As witnessed by many discussions on Stack Overflow4, there is no consensus on which of these three technologies is the most appropriate for any given project, as it may depend on many project-related characteristics, technological choices or even personal preferences.

One should also note that the use of these technologies is not exclusive. A project may use all of these technologies simultaneously. These technologies may even be used together within the same Java source code files. 3.2

In order to obtain a representative project sample, we based our empirical analyses on Java projects belonging the GitHub project corpus proposed by Allamanis and Sutton [ 16 ]. Among these projects, 13,307 still had an available Git repository on 24 March 2015.

In order to carry out our empirical study, we selected 2,457 projects from this project corpus for which at least one of the commits contained a reference to either jdbc, jpa or hbm. For each selected project, we extracted the existing relations between source code and database entities from the first commit of each week, and we obtained an historical view of all the files that can be related to a particular technology or to a particular framework.

duration (in weeks) # commits # contributors # files in HEAD # Java files in HEAD mean

76 1317

12 1058 512

Table 1 shows some of the characteristics of the selected projects. The distribution of metrics values is 3oracle.com/technetwork/java/javaee/tech/ persistence-jsp-140049.html

4see for example stackoverflow.com/questions/Q with Q = 1607819, 2397016, 2560500 or 530215. highly skewed, suggesting evidence of a Pareto principle [ 17 ]. The duration is expressed in weeks between the first and the last commit.

Figure 1 reports the number of projects per considered technology, taking the entire lifetime of each project into account. We observe that the project sample is relatively unbalanced with respect to the presence of each technology, but each pair of technologies is still represented in a quite a number of projects. 4

RQ1 When and in which order are database technologies introduced in a project? Introducing a new technology in a software project comes with a certain cost. A common policy is therefore to introduce such a technology only if the expected benefits outweigh the expected cost.

For each project, we analysed at what moment in the projects’ lifetime each considered technology got introduced. The answer appears to depend on the duration of the considered projects. To minimise the e↵ect of project duration, we normalised the lifetime of each project into a range between 0 (the start of the project) and 1 (the last considered commit). two distributions of the introduction time of the technology in a project. The first distribution (left) considers the first time a technology gets introduced in a project. The second distribution (right) considers the introduction of the technology in a project that already had a technology before. As expected, we observe that more than 50% of the introductions of a first technology are done in the first 10% of the project’s lifetime. For technologies introduced after an existing one, the distribution tends to be flatter.

We also observe that the two distributions for jdbc present less di↵erences than the ones related to jpa or hbm. To achieve this, we performed a KolmogorovSmirnov statistical test for each pair of distributions related to jdbc, jpa and hbm. The tests show that the two distributions associated to each technology are significantly di↵erent (p-values are lower than 10 6). This may indicate that for jdbc, the moment of introduction is less a↵ected by the presence of another technology than for hbm and jpa.

We saw that the time at which a technology is introduced in a project varies depending on the presence of another technology in this project. What are the technologies that are more likely to be succeeded by another one?

To answer this question, we use the statistical technique of survival analysis to estimate the probability that a technology does not remain the last introduced one in a project lifetime. Survival analysis [ 18 ] creates a model estimating the survival rate of a population over time, considering the fact that some elements of the population may leave the study, and for some other elements the event of interest does not occur during the observation period. In our case, the observed event is the introduction in a project of another technology after an existing one.

Figure 3 shows the survival rates for each considered technology. We observe that hbm has a much lower survival rate (i.e., a lower probability of staying the last introduced technology for a long time) than the other technologies. We also observe that, during the first 10% of the projects’ lifetime, the survival rates of hbm decrease by 30%, representing a more important decrease than for the other two technologies. This implies that hbm is usually quickly replaced or complemented by another technology.

Figure 1 showed that around 23% of the projects use two or more database technologies in their lifetime, but these are not necessarily used simultaneously. We therefore identified which combinations of technologies actually co-occur in the selected Java projects. Frequent co-occurrences would reveal which technologies are complementary, and which technologies are used as supporting technologies of other ones. For each pair of technologies, we counted the number of projects in which these technologies actually co-occur, and in which order they were introduced in these projects. The results are summarised in Table 2.

(A, B) ! # projects # co-occurrences % co-occurrences startA < startB startA > startB startA = startB

Among all projects that use multiple technologies during their lifetime we observe a very high proportion of co-occurring technologies. More specifically, in 97.3% (488+148+77 out of 497+152+84) of all the situations in which two distinct technologies were used during a project’s lifetime, they were used simultaneously. Around 41% (189+75+28 out of 488+148+77) of all pairs of cooccurring technologies were introduced simultaneously (startA = startB), implying that around 59% of all pairs of co-occurring technologies concern projects in which the technologies were introduced at di↵erent moments (startA 6= startB).

Considering the number of projects in which the introduction of a technology A was observed before the use of a technology B, it seems that jpa tends to succeed to hbm more often than the contrary (37 versus 19 observations). Similarly, hbm tends to succeed to jdbc more often than the contrary (50 versus 27 observations). We did not identify such an order for jpa and jdbc (151 versus 157 observations).

Summary. All considered technologies are introduced early in the projects’ lifetimes, even for projects that already use another technology. The number of projects in which multiple technologies co-occur is proportionally important. The order in which these technologies are introduced suggests that hbm is often succeeded by jdbc or jpa.

RQ2 How does the introduction of a new technology in a project a↵ect the already included ones? As multiple database access technologies are used in many projects, either simultaneously or one after the other, it is useful to study how the introduction of a new technology can impact the use of an already included one. This impact, if it occurs, could result in an increased or decreased usage of the already included technology. We therefore identified and counted for which projects the introduction of a new technology causes an increasing use of the older technology, a decreasing use, or no observable change in the use of the already included technology.

To qualify the impact, we rely on the first derivative of the number of files related to an existing technology. We computed and compared the mean of this derivative for two 8-week periods: the first period strictly precedes the moment of introduction of the new technology, and the second period immediately follows the moment of introduction.

In the following, we will use the term variation to denote the di↵erence between the mean of the second period and the mean of the first period. The variation of a technology is easy to interpret: a positive value indicates an increasing use of the existing technology while a negative value indicates a decreasing use of the existing technology

Figure 4 shows the distribution of the variation for each pair of technologies. We observe that jdbc and hbm cause a slight positive impact on the use of existing technologies (since the variation tends to be positive in 75% of all cases). Notice the important variation induced by introducing hbm in projects using jpa. The converse is not true: introducing jpa in a project that already uses hbm implies a negative variation for hbm.

Figure 4 only identifies global trends in our project corpus. It does not allow to identify trends within individual projects. Figure 5 therefore distinguishes the projects that exhibit a positive variation (blue curve), a negative variation (red curve) or no variation (green curve) for several time intervals after the introduction of the new technology.

Regardless of the considered pair of technologies, with the notable exception of the pairs (jpa after hbm) and (hbm after jpa), both the number of projects having no variation and the number of projects having a positive variation are systematically greater than the number of projects exhibiting a negative variation.

Figure 6 shows survival curves, using a KaplanMeier estimator, of the probability that a project keeps more than a threshold of 25% of its files related to an already included technology after the introduction of new one. We tried di↵erent threshold values and they all lead to the same conclusions.

Again, we observe that the most distinct behaviours are exhibited by jpa and hbm: the probability to keep more than 25% of files related to hbm drops below 0.55 about 20 weeks after introducing jpa, while the probability for jpa files drops to a little more than 0.6 about 19 weeks after introducing hbm. This analysis corroborates our previous observations: introducing jpa or hbm does not negatively impact the use of jdbc, and conversely. We also observe from Figures 5 and 6 that most of the impact happens in the first weeks after introducing the new technology.

Summary. Introducing a new technology generally induces, in the short term, an increase of the presence of the already included technology, with the notable exception of the introduction of jpa on a project that already makes use of hbm. This suggests that, contrary to the promises of ORM technologies, new technologies do not tend to replace existing ones but rather complement them.

RQ3 To which extent does the introduction of a technology impact the way in which a project accesses the database? From the results of RQ1 we observed that, if a project uses multiple database access technologies over its lifetime, these technologies tend to co-occur. At a more fine-grained level, we are interested in the impact of the introduction of a technology on the files that already relate to a previously used technology. 6.1

Let us first study the co-occurrences of di↵erent technologies at file level without taking the evolutionary aspect into account. Figure 7 shows, for each pair of technologies, the distribution across projects of the ratio between the number of files that relate to each, or both, technologies, and the number of files that relate to any of these technologies. For each pair of technologies, only projects in which both technologies have been used at some point in their lifetime have been retained as elements of the distribution.

It turns out that pairs of technologies including jdbc present similar profiles: most projects contain a small proportion of files using both technologies. A twosided Kolmogorov-Smirnov test confirms this similarity between distributions: we cannot reject the null hypothesis that states that the distributions associated to the proportion of files using a single technology are identical (p = 0.877 and 0.287, respectively). We conclude that jdbc is generally not used in the same files as jpa and hbm.

The pair of technologies jpa and hbm presents a different behaviour. The three distributions of the proportion of files that only relate to these technologies are significantly di↵erent (we reject the null hypothesis with p < 0.001). This result, combined with the form of the distributions, suggests that, for projects having used jpa and hbm, a file is likely to relate either to jpa only or to both jpa and hbm. In addition to this, the proportion of files that use both hbm and jpa is more important than for the other considered pairs of technologies.

Summary. There is a clear separation between files using jdbc and files using the two other technologies. For the combination of hbm and jpa, a partial, asymmetric overlap exists at file level: hbm is often used in the same files as jpa, while jpa is rarely used in combination with another technology in the same file. 6.2

Let us now look at the same question from an evolutionary point of view, by assessing the impact, at file-level, of introducing a new technology in a project that already uses another technology to access the database. To do this, we study how the files related to an existing technology get changed after introduction of the new technology.

Let us associate a migration profile to each project at di↵erent points in time after the introduction of the new technology. This migration profile reflects how the files related to the old technology are impacted. It is computed as follows:

Let P be a project and T = {jdbc, hbm, jpa} the considered technologies. For each point in time t for P and each technology A 2 T we define relatedP (A, t) as the (possibly empty) subset of (fully qualified) filenames of P in which technology A was detected at time t.

For every pair of distinct technologies (A, B) 2 T ⇥ T , we write M = (P, A, B) if P is a project in which technology B gets introduced while a technology A is already in use. Let tM denote the point in time of this introduction and FM = relatedP (A, tM ) the set of filenames associated to technology A. For each t tM we associate to each f 2 FM a label in L = {residual, removed, complemented, replaced} as follows: residual if f 2 relatedP (A, t) \ relatedP (B, t) removed if f 2 / relatedP (A, t) [ relatedP (B, t) complemented if f 2 relatedP (A, t) \ relatedP (B, t) replaced if f 2 relatedP (B, t) \ relatedP (A, t) Given M , we also associate to each t tM a set of labels mpM(t) ✓ L . A label L 2 L belongs to mpM(t) if, among the labels associated to each f 2 FM at time t, no other label occurs more frequently than L.

Finally, the migration profile of M at time t is a unique label from mpM(t) selected based on the total order replaced > complemented > removed > residual. This total order privileges migration profiles that correspond to the adoption of the new technology.

As the choice of a total order could have altered the results of our analysis, we compared the results obtained with several total orders, and we observed only slight local variations. This is not surprising as there are only 72 pairs (M, t) such that |mpM(t)| > 1, representing 1.78% of all the considered pairs.

Figure 8 shows the evolution of the proportion of projects with a given migration profile. For the sake of readability, we only present results for complemented , replaced , and removed . The results for residual can be deduced from these, by taking the complement of complemented , replaced and removed .

We observe that, for each considered pair of technologies, and for each time delay (expressed in weeks) after the introduction of the new technology, most projects relate to the residual migration profile, implying that projects tend not to adapt their existing database access files to make use of the newly introduced technology. This is especially true for projects introducing jdbc after jpa or hbm.

The second dominant migration profile is removed . Regardless of the considered pair of technologies, more and more projects are associated to this migration profile. Over time, an increasing number of projects tend to reduce the number of files relating to the first considered technology. The predominance of residual and removed migration profiles seems to convey that, in many cases, files that related to the existing technology are not prone to use the newly introduced technology. Instead, they either continue to use the first technology or they tend to lose any relation to database access management.

The two other migration profiles, complemented and replaced , indicate an e↵ective file migration from the existing technology to the newly introduced one. Such cases appear to be much less represented in our corpus, with the exception of projects in which jpa or jdbc is introduced after hbm. This is especially the case when jpa is introduced in a project using hbm: the files that were related to hbm become (sometimes exclusively) related to jpa.

Summary. Di↵erent technologies generally do not tend to co-occur in the same set of files, except, to some extent, when jpa and hbm are used together. We do not observe a true migration in technology usage: files that are related to a given technology do not tend to adopt the newly introduced technology, except for projects that migrate from hbm to another technology.