Dynamic code evolution for Java

Würthinger, Thomas; Wimmer, Christian; Mössenböck, Hanspeter

doi:10.1145/1852761.1852764

Cited by 57 publications

(41 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…A causally connected dynamic meta-level for debugging that can support run-time evolution can be build for Java by combining the currently available debugging infrastructure found in JPDA [Ora13b] with the incremental updating facilities of the DCE VM project [WWS10] or those found in the JRebel vm-plugin [Zer12] (see also Section 4). Support for semantic instrumentation can be build on top of solutions for bytecode manipulation or reflective intercession for Java like those in Iguana/J [RC00], Reflex [TBN01], ASM [BLC02] or JavaAssist [CN03].…”

Section: Discussion: Implementing Mercury In Javamentioning

confidence: 99%

See 1 more Smart Citation

Mercury: Properties and Design of a Remote Debugging Solution using Reflection.

Papoulias¹,

Bouraqadi²,

Fabresse³

et al. 2015

JOT

View full text Add to dashboard Cite

Remote debugging facilities are a technical necessity for devices that lack appropriate input/output interfaces (display, keyboard, mouse) for programming (e.g., smartphones, mobile robots) or are simply unreachable for local development (e.g., cloud-servers). Yet remote debugging solutions can prove awkward to use due to re-deployments. Empirical studies show us that on average 10.5 minutes per coding hour (over five 40-hour work weeks per year) are spent for re-deploying applications (including re-deployments during debugging). Moreover current solutions lack facilities that would otherwise be available in a local setting because it is difficult to reproduce them remotely. Our work identifies three desirable properties that a remote debugging solution should exhibit, namely: run-time evolution, semantic instrumentation and adaptable distribution. Given these properties we propose and validate Mercury, a remote debugging model based on reflection. Mercury supports run-time evolution through a causally connected remote meta-level, semantic instrumentation through the reification of the underlying execution environment and adaptable distribution through a modular architecture of the debugging middleware.

show abstract

Section: Discussion: Implementing Mercury In Javamentioning

confidence: 99%

“…JRebel and DCE The DCE VM [WWS10] and Jrebel [Zer12] are both modifications for the Java virtual machine that support redefinition of loaded classes at runtime. Although these modifications of the underlying VM are not a solution for debugging themselves, they do provide incremental updating facilities for remote targets.…”

Section: Existing Solutionsmentioning

confidence: 99%

Mercury: Properties and Design of a Remote Debugging Solution using Reflection.

Papoulias¹,

Bouraqadi²,

Fabresse³

et al. 2015

JOT

View full text Add to dashboard Cite

show abstract

“…-how to modify the code during its execution (several tools, -as JavAdaptor [61,62], Javeleon [38] and jRebel [41]-and some JVM extensions -as Java hotspot and the Wurthinger et al's work [69]-help with this issue); -how to associate the design information to the running code (normally models and code are statically coupled and the generation of the new code is model-driven); -how to face the natural gap between code and design information especially in case of evolution [19,68].…”

Section: Self-adjusting: Reflecting On the Modelmentioning

confidence: 99%

Evolution as ≪Reflections on the Design≫

Cazzola

2014

Models@run.time

View full text Add to dashboard Cite

Abstract. No system escapes from the need of evolving either to fix bugs, to be reconfigured or to add new features. To evolve becomes particularly problematic when the system to evolve cannot be stopped.Traditionally the evolution of a continuously running system is tackled on by calculating all the possible evolutions in advance and coding them in the artifact itself. This approach gives origin to the code pollution phenomenon where the code is polluted by code that could never be applied. The approach has the following defects: i) code bloating, ii) it is impossible to predict any possible change and iii) the code becomes hard to read and maintain.Computational reflection by definition allows an artifact to introspect and to intercede on its own structure and behavior endowing, therefore, a reflective artifact with (potentially) the ability of self-evolving. Furthermore, to deal with the evolution as a nonfunctional concern can limit the code pollution phenomenon.To bring the design information (model and/or architecture) at runtime provides the artifact with a basic knowledge about itself to reflect on when a change is necessary and on how to deploy it. The availability of such a knowledge at run-time enables the designer of postponing the planning and the coding of the evolution to when and only when really necessary. Reflection permits to separate the evolution from the artifact and the design information allows a (semi-)automatic planning of how the artifact should evolve when necessary.In this contribution, we overview the role that reflection and design information have in the development of self-evolving artifacts. Moreover, we summarize the lesson learned as a high-level reflective architecture to support dynamic self-evolution in various contexts and we show how some of the existing frameworks adhere to such an architecture and how the kind of evolution affects their structure.

show abstract

“…For example, some updates will be rejected if they are not provably type-safe [20] or might produce run-time errors [33].…”

Section: Other Approachesmentioning

confidence: 99%

Using first-class contexts to realize dynamic software updates

Wernli

Gurtner

Nierstrasz

2011

Proceedings of the International Workshop on Smalltalk Technologies

View full text Add to dashboard Cite

Applications that need to be updated but cannot be easily restarted must be updated at run-time. We evaluate the reflective facilities of Smalltalk with respect to dynamic software and the state-of-the-art in this field. We conclude that while fine for debugging, the existing reflective facilities are not appropriate for dynamically updating production systems under constant load. We propose to enable dynamic updates by introducing first-class contexts as a mechanism to allow multiple versions of objects to coexist. Object states can be dynamically migrated from one context to another, and can be kept in sync with the help of bidirectional transformations. We demonstrate our approach with ActiveContext, an extension of Smalltalk with first-class contexts. ActiveContext eliminates the need for a system to be quiescent for it to be updated. ActiveContext is realized in Pinocchio, an experimental Smalltalk implementation that fully reifies the VM to enable radical extensions. We illustrate dynamic updates in ActiveContext with a typical use case, present initial benchmarks, and discuss future performance improvements.

show abstract

Dynamic code evolution for Java

Cited by 57 publications

References 31 publications

Mercury: Properties and Design of a Remote Debugging Solution using Reflection.

Mercury: Properties and Design of a Remote Debugging Solution using Reflection.

Evolution as ≪Reflections on the Design≫

Using first-class contexts to realize dynamic software updates

Contact Info

Product

Resources

About