Proactive Empirical Assessment of New Language Feature Adoption via Automated Refactoring: The Case of Java 8 Default Methods

Programming languages and platforms improve over time, sometimes resulting in new language features that offer many benefits. However, despite these benefits, developers may not always be willing to adopt them in their projects for various reasons. In this paper, we describe an empirical study where we assess the adoption of a particular new language feature. Studying how developers use (or do not use) new language features is important in programming language research and engineering because it gives designers insight into the usability of the language to create meaning programs in that language. This knowledge, in turn, can drive future innovations in the area. Here, we explore Java 8 default methods, which allow interfaces to contain (instance) method implementations. Default methods can ease interface evolution, make certain ubiquitous design patterns redundant, and improve both modularity and maintainability. A focus of this work is to discover, through a scientific approach and a novel technique, situations where developers found these constructs useful and where they did not, and the reasons for each. Although several studies center around assessing new language features, to the best of our knowledge, this kind of construct has not been previously considered. Despite their benefits, we found that developers did not adopt default methods in all situations. Our study consisted of submitting pull requests introducing the language feature to 19 real-world, open source Java projects without altering original program semantics. This novel assessment technique is proactive in that the adoption was driven by an automatic refactoring approach rather than waiting for developers to discover and integrate the feature themselves. In this way, we set forth best practices and patterns of using the language feature effectively earlier rather than later and are able to possibly guide (near) future language evolution. We foresee this technique to be useful in assessing other new language features, design patterns, and other programming idioms.

💡 Research Summary

The paper presents a proactive empirical study of how developers adopt a newly introduced language feature—Java 8 default methods—by automatically refactoring existing open‑source projects and submitting the changes as pull requests. The authors argue that most prior work on language feature adoption has been passive, relying on observation of natural uptake or surveys. In contrast, their “proactive assessment” technique actively introduces the feature into real codebases, preserving program semantics, and then measures developers’ reactions.

To enable this, the authors built an automated refactoring tool that scans a codebase for methods that are duplicated across multiple implementing classes, extracts the common implementation, and inserts it as a default method in the corresponding interface. The transformation is validated by running the project’s existing test suite before and after the change; only if all tests still pass is the pull request generated. This ensures that the proposed modification does not alter observable behavior.

Nineteen actively maintained Java projects on GitHub were selected based on size, test coverage, and activity. For each project the tool produced at least one pull request that added a default method without changing the public API. The authors then recorded whether the pull request was accepted, rejected, or ignored, and collected developers’ comments, code review discussions, and any subsequent modifications. Quantitative results show that only 7 of the 19 projects accepted the change (≈37 %). Qualitative analysis of the feedback reveals four major categories of resistance:

1. Design‑contract concerns – many teams view interfaces strictly as contracts; a default implementation is seen as a violation of that principle, especially when the default could mask required behavior.
2. Implementation‑specific logic – default methods that embed logic tied to a particular class hierarchy are perceived as risky because they may unintentionally affect other implementations.
3. Testing and regression risk – projects with limited automated testing are reluctant to introduce new execution paths, fearing hidden regressions.
4. Existing alternatives – teams already using abstract classes, adapters, or other patterns consider default methods redundant and not worth the migration effort.

Conversely, acceptance was more likely when the interface was lightweight, the duplicated implementation was truly generic, the project already emphasized API evolution and backward compatibility, and the test infrastructure was robust enough to quickly validate the change.

From these observations the authors derive several practical implications. First, the usefulness of default methods is highly context‑dependent; language designers should provide clear guidance on when default methods align with interface‑as‑contract philosophies. Second, automated refactoring can serve as a “preview” mechanism, exposing developers to a feature they might otherwise overlook, thereby accelerating adoption where appropriate. Third, the proactive assessment methodology itself is portable: it can be applied to other language features (e.g., lambdas, modules), design patterns, or idioms, offering a systematic way to gauge real‑world usability before a feature matures.

The paper concludes that proactive, tool‑driven insertion of language features, combined with rigorous semantic validation, yields richer insight into developer preferences than passive observation alone. It also highlights the importance of test automation, clear design contracts, and existing architectural patterns in shaping adoption decisions. Future work will extend the approach to a broader set of languages and explore automated feedback loops that refine the refactoring suggestions based on developer responses, ultimately informing language evolution and tooling strategies.