2,483 research outputs found
Scala Server Faces
Progress in the Java language has been slow over the last few years. Scala is emerging as one of the probable successors for Java with features such as type inference, higher order functions, closure support and sequence comprehensions. This allows object-oriented yet concise code to be written using Scala. While Java based MVC frameworks are still prevalent, Scala based frameworks along with Ruby on Rails, Django and PHP are emerging as competitors. Scala has a web framework called Lift which has made an attempt to borrow the advantages of other frameworks while keeping code concise. Since Sunâs MVC framework, Java Server Faces 2.0 and its future versions seem to be heading in a reasonably progressive direction; I have developed a framework which attempts to overcome its limitations. I call such a framework âScala Server Facesâ. This framework provides a way of writing Java EE applications in Scala yet borrow from the concept of âconvention over configurationâ followed by rival web frameworks. Again, an Eclipse tool is provided to make the programmer\u27s task of writing code on the popular Eclipse platform. Scala Server Faces, the framework and the tool allows the programmer to write enterprise web applications in Scala by providing features such as templating support, CRUD screen generation for database model objects, an Ant script to help deployment and integration with the Glassfish Application Server
Ghost: A uniform and general-purpose proxy implementation
International audienceA proxy object is a surrogate or placeholder that controls access to another target object. Proxy objects are a widely used solution for different scenarios such as remote method invocation, future objects, behavioral reflection, object databases, inter-languages communications and bindings, access control, lazy or parallel evaluation, security, among others. Most proxy implementations support proxies for regular objects but are unable to create proxies for objects with an important role in the runtime infrastructure such as classes or methods. Proxies can be complex to install, they can have a significant overhead, they can be limited to certain kind of classes, etc. Moreover, proxy implementations are often not stratified and they do not have a clear separation between proxies (the objects intercepting messages) and handlers (the objects handling interceptions). In this paper, we present Ghost: a uniform and general-purpose proxy implementation for the Pharo programming language. Ghost provides low memory consuming proxies for regular objects as well as for classes and methods. When a proxy takes the place of a class, it intercepts both the messages received by the class and the lookup of methods for messages received by its instances. Similarly, if a proxy takes the place of a method, then the method execution is intercepted too
Run-time Variability with First-class Contexts
Software must be regularly updated to keep up with changing requirements. Unfortunately, to install an update, the system must usually be restarted, which is inconvenient and costly. In this dissertation, we aim at overcoming the need for restart by enabling run-time changes at the programming language level. We argue that the best way to achieve this goal is to improve the support for encapsulation, information hiding and late binding by contextualizing behavior. In our approach, behavioral variations are encapsulated into context objects that alter the behavior of other objects locally. We present three contextual language features that demonstrate our approach. First, we present a feature to evolve software by scoping variations to threads. This way, arbitrary objects can be substituted over time without compromising safety. Second, we present a variant of dynamic proxies that operate by delegation instead of forwarding. The proxies can be used as building blocks to implement contextualization mechanisms from within the language. Third, we contextualize the behavior of objects to intercept exchanges of references between objects. This approach scales information hiding from objects to aggregates. The three language features are supported by formalizations and case studies, showing their soundness and practicality. With these three complementary language features, developers can easily design applications that can accommodate run-time changes
A Type System for First-Class Layers with Inheritance, Subtyping, and Swapping
Context-Oriented Programming (COP) is a programming paradigm to encourage
modularization of context-dependent software. Key features of COP are
layers---modules to describe context-dependent behavioral variations of a
software system---and their dynamic activation, which can modify the behavior
of multiple objects that have already been instantiated. Typechecking programs
written in a COP language is difficult because the activation of a layer can
even change objects' interfaces. Inoue et al. have informally discussed how to
make JCop, an extension of Java for COP by Appeltauer et al., type-safe.
In this article, we formalize a small COP language called ContextFJ
with its operational semantics and type system and show its type soundness. The
language models main features of the type-safe version of JCop, including
dynamically activated first-class layers, inheritance of layer definitions,
layer subtyping, and layer swapping
Reify Your Collection Queries for Modularity and Speed!
Modularity and efficiency are often contradicting requirements, such that
programers have to trade one for the other. We analyze this dilemma in the
context of programs operating on collections. Performance-critical code using
collections need often to be hand-optimized, leading to non-modular, brittle,
and redundant code. In principle, this dilemma could be avoided by automatic
collection-specific optimizations, such as fusion of collection traversals,
usage of indexing, or reordering of filters. Unfortunately, it is not obvious
how to encode such optimizations in terms of ordinary collection APIs, because
the program operating on the collections is not reified and hence cannot be
analyzed.
We propose SQuOpt, the Scala Query Optimizer--a deep embedding of the Scala
collections API that allows such analyses and optimizations to be defined and
executed within Scala, without relying on external tools or compiler
extensions. SQuOpt provides the same "look and feel" (syntax and static typing
guarantees) as the standard collections API. We evaluate SQuOpt by
re-implementing several code analyses of the Findbugs tool using SQuOpt, show
average speedups of 12x with a maximum of 12800x and hence demonstrate that
SQuOpt can reconcile modularity and efficiency in real-world applications.Comment: 20 page
Flexible Correct-by-Construction Programming
Correctness-by-Construction (CbC) is an incremental program construction
process to construct functionally correct programs. The programs are
constructed stepwise along with a specification that is inherently guaranteed
to be satisfied. CbC is complex to use without specialized tool support, since
it needs a set of predefined refinement rules of fixed granularity which are
additional rules on top of the programming language. Each refinement rule
introduces a specific programming statement and developers cannot depart from
these rules to construct programs. CbC allows to develop software in a
structured and incremental way to ensure correctness, but the limited
flexibility is a disadvantage of CbC. In this work, we compare classic CbC with
CbC-Block and TraitCbC. Both approaches CbC-Block and TraitCbC, are related to
CbC, but they have new language constructs that enable a more flexible software
construction approach. We provide for both approaches a programming guideline,
which similar to CbC, leads to well-structured programs. CbC-Block extends CbC
by adding a refinement rule to insert any block of statements. Therefore, we
introduce CbC-Block as an extension of CbC. TraitCbC implements
correctness-by-construction on the basis of traits with specified methods. We
formally introduce TraitCbC and prove soundness of the construction strategy.
All three development approaches are qualitatively compared regarding their
programming constructs, tool support, and usability to assess which is best
suited for certain tasks and developers.Comment: arXiv admin note: substantial text overlap with arXiv:2204.0564
- âŠ