Genericity in Java: persistent and database systems implications

Alagić, Suad; Royer, Mark

doi:10.1007/s00778-006-0042-x

Cited by 7 publications

(6 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Java's generic type features are quite complicated and problematic [1], unlike the C# solution [23]. There also exists an extended virtual platform for JML [20] which allows management of JML constraints.…”

Section: Extending Jml To Support Types As Theoriesmentioning

confidence: 99%

“…Some languages also support, in the context of the partial order of the type system, imposition of requirements on the type parameters, so called bounded parametric polymorphism. These features in some cases come with nontrivial difficulties [1]. Object-oriented assertion languages such as JML [13], OCL [22] and Spec# [4] are yet to develop full support for parametric types.…”

Section: Adding Semantics To Generic Specificationsmentioning

confidence: 99%

See 1 more Smart Citation

Algebraic specification techniques for parametric types with logic-based constraints

Briggs

Alagić

2009

Proceedings of the 2009 ACM Symposium on Applied Computing

Self Cite

View full text Add to dashboard Cite

Mainstream object-oriented languages now offer capabilities of generic types with bounded type parameters, but they typically do not provide support for specifying semantic requirements on the type parameters' methods beyond conformance of signatures. Regrettably, even object-oriented assertion languages, such as JML, have nontrivial limitations in this regard. Yet many interesting parameterized types require additional semantic features if they are to function as intended. We illustrate the issues with a case study of project scheduling based on the Project Management Institute's generic characterization of task breakdowns. We consider algebraic techniques for instantiating parametric types in such a way that the semantic requirements expressed by logic-based constraints propagate to the instantiating types. These techniques argue for more general bindings of actual type parameters for the formal ones which do not have the restrictions of current programming languages. We show that types equipped with constraints should be viewed as theories, and the bindings as morphisms of types as theories. We translate these software specifications into theories in the PVS specification language. These proposals lead to conclusions about language features for more general, semantic bindings of the actual for the formal type parameters, at least in the assertion languages.One of the more recent features of mainstream objectoriented programming languages (Eiffel [16], C++ [21], C# [12], Java 5.0 [10]) is mechanisms for higher order abstractions, generic data types that are parameterized by type variables. Some languages also support, in the context of the partial order of the type system, imposition of requirements on the type parameters, so called bounded parametric polymorphism. These features in some cases come with nontrivial difficulties [1]. Object-oriented assertion languages such as JML [13], OCL [22] and Spec# [4] are yet to develop full support for parametric types.The type error detection a compiler can perform must be restricted to decidable questions or decidable approximations of undecidable questions. When a client module uses a service provided by another module, where correct functioning of the client requires certain specific behavior, the compiler cannot determine if the behavior meets the client's needs. It can only report whether the basic structural demands, the existence of methods with certain type signatures, are met.Some generic types, such as ordered pairs, have meaningful operations that are independent of particular features of the type parameters. Often, however, when a generic type imposes type bounds on its parameters, it does so because it requires not only the presence of certain methods, but also that those methods' behaviors satisfy certain semantic conditions. For example, if a module implementing a generic sort expects that the concrete type has a total order, the algorithm will not yield the specified result if the binary relation used is not a total order.Although a compiler cannot enf...

show abstract

Section: Extending Jml To Support Types As Theoriesmentioning

confidence: 99%

Section: Adding Semantics To Generic Specificationsmentioning

confidence: 99%

Algebraic specification techniques for parametric types with logic-based constraints

Briggs

Alagić

2009

Proceedings of the 2009 ACM Symposium on Applied Computing

Self Cite

View full text Add to dashboard Cite

show abstract

“…in [1,22,14,13,2] and implemented in .NET. The research leading to the EGO compiler, culminating in the present article, shows instead that even a compile-time approach can be exploited similarly to other existing Java language features such as e.g.…”

Section: The Ego Compilermentioning

confidence: 99%

“…This means that generic types are simply introduced as a compile-time abstraction to enforce type-safety; they are erased to standard types by the compilation process, and hence they never enter the runtime domain of the Java Virtual Machine (JVM). As described in detail in [2,22] this makes generics (i) hardly fit important Java frameworks such as Serialization and Reflection; and (ii) differ from standard Java types as far as type-dependent operations are concerned (cast conversions, type tests through instanceof operator, array operations). But most importantly, erasure causes the so-called heap pollution problem: certain cast operations are statically accepted (with a warning) and succeed at runtime, but can later cause any field access or method invocation to unpredictably fail.…”

Section: Introductionmentioning

confidence: 98%

See 1 more Smart Citation

On the reification of Java wildcards

Cimadamore

Viroli

2008

Science of Computer Programming

View full text Add to dashboard Cite

a b s t r a c tProviding runtime information about generic types -that is, reifying generics -is a challenging problem studied in several research papers in the last years. This problem is not tackled in current version of the Java programming language (Java 6), which consequently suffers from serious safety and coherence problems. The quest for finding effective and efficient solutions to this problem is still open, and is further made more complicated by the new mechanism of wildcards introduced in Java J2SE 5.0: its reification aspects are currently unexplored and pose serious semantics and implementation issues.In this paper, we discuss an implementation support for wildcard types in Java. We first analyse the problem from an abstract viewpoint, discussing the issues that have to be faced in order to extend an existing reification technique so as to support wildcards, namely, subtyping, capture conversion and wildcards capture in method calls. Secondly, we present an implementation in the context of the EGO compiler. EGO is an approach for efficiently supporting runtime generics at compile-time: synthetic code is automatically added to the source code by the extended compiler, so as to create generic runtime type information on a by need basis, store it into object instances, and retrieve it when necessary in typedependent operations. The solution discussed in this paper makes the EGO compiler the first reification approach entirely dealing with the present version of the Java programming language.

show abstract

Modularizing application and database evolution - an aspect-oriented framework for orthogonal persistence

Pereira

Perez-Schofield

Ortín

2016

Softw. Pract. Exper.

View full text Add to dashboard Cite

Summary In the maintenance of software applications, database evolution is one common difficulty. In object‐oriented databases, this process comprises schema evolution and instance adaptation. Both tasks usually require significant effort from programmers and database administrators. In this paper, we propose orthogonal persistence and aspect‐oriented programming to support semi‐transparent database evolution. A default mechanism for instance evolution is defined, but the user may provide modularized solutions using the aspect‐oriented paradigm. We present our framework AOF4OOP to test the feasibility of our proposed approach. This prototype allows programmes to transparently access data in other versions of the database schema. We evaluate our framework, comparing it to related approaches using two real applications and measuring the improvement of the productivity of the programmer. Copyright © 2016 John Wiley & Sons, Ltd.

show abstract

Genericity in Java: persistent and database systems implications

Cited by 7 publications

References 23 publications

Algebraic specification techniques for parametric types with logic-based constraints

Algebraic specification techniques for parametric types with logic-based constraints

On the reification of Java wildcards

Modularizing application and database evolution - an aspect-oriented framework for orthogonal persistence

Contact Info

Product

Resources

About