| Malcolm P. Atkinson, Mick J. Jordan, Laurent Daynes, and Susan Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996. |
....modi cations of class de nitions are applied; all object instances are converted (eagerly or lazily, but once and forever) to conform to the latest schema. The schema evolution approach is used in Orion [7] OTGEN [40] O2 [29, 52] GemStone [17, 48] Objectivity DB [47] Versant [50] and PJama [6, 5] systems, and is the only approach available in commercial RDBMS. An extensive survey of the previous schema evolution systems can be found in [30] None of the previous schema evolution systems provide a way of executing upgrades eciently both in space and time, while allowing programmers to ....
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
....This section shows how ownership types and e ects clauses can be used to enable modular reasoning about the correctness of upgrades in a persistent object store. The desire to achieve such reasoning was the motivation for our work on ownership types for encapsulation. A persistent object store [46, 5, 9, 17, 18, 29, 56] contains conventional objects similar to what one might nd in an object oriented language such as Java. Applications access persistent objects within atomic transactions, since this is necessary to ensure consistency for the stored objects; transactions allow for concurrent access and they mask ....
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
....later and shared with other applications. The database acts as an extension of an object oriented programming language such as Java, allowing programs access to long lived objects in a manner analogous to how they manipulate ordinary objects whose lifetime is determined by that of the program [37, 24, 13, 43, 12, 5]. The objects stored in an OODB may live a long time and as a result there may be a need to upgrade them, that is, change their code and storage representation. An upgrade can improve an object s implementation, to make it run faster or to correct an error; extend the object s interface, e.g. by ....
....object via multiple potentially incompatible interfaces and are very di erent from the eciency and correctness issues in the evolutionbased upgrade systems. The schema evolution approach is used in Orion [6] OTGEN [36] O2 [24, 53] GemStone [12, 45] Objectivity DB [44] Versant [49] and PJama [5, 4] systems, and is the only approach available in any commercial RDBMS. None of the existing schema evolution systems provides both expressive and ecient upgrades. Furthermore, none bases the correctness of the upgrade system on the property of encapsulation or ownership types. Work in O2 uses ....
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
....later and shared with other applications. The database acts as an extension of an object oriented programming language such as Java, allowing programs access to long lived objects in a manner analogous to how they manipulate ordinary objects whose lifetime is determined by that of the program [37, 24, 13, 43, 12, 5]. The objects stored in an OODB may live a long time and as a result there may be a need to upgrade them, that is, change their code and storage representation. An upgrade can improve an object s implementation, to make it run faster or to correct an error; extend the object s interface, e.g. by ....
....object via multiple potentially incompatible interfaces and are very di#erent from the e#ciency and correctness issues in the evolutionbased upgrade systems. The schema evolution approach is used in Orion [6] OTGEN [36] O2 [24, 53] GemStone [12, 45] Objectivity DB [44] Versant [49] and PJama [5, 4] systems, and is the only approach available in any commercial RDBMS. None of the existing schema evolution systems provides both expressive and e#cient upgrades. Furthermore, none bases the correctness of the upgrade system on the property of encapsulation or ownership types. Work in O2 uses ....
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
....All objects reachable from persistent roots are automatically stored in persistent storage by the system the rest of the objects are garbage collected. Since Java has no persistence model built into it, many research systems have been proposed that add persistence to Java. These include PJama [3], JPS [6] GemStone J [17] and PSEJ [42] Of these, only PSEJ is JVM compatible. PSEJ uses the technique of bytecode rewriting. Bytecode rewriting has become an established technique for extending Java. But PSEJ has severe problems both in terms of its semantics and its performance. For example, ....
....system must provide a mechanism for upgrading the persistent objects. These upgrades involve 2 changes to the code implementing the persistent objects, as well as changes to the persistent objects themselves. Much research has been done on software evolution in persistent object systems. PJama [3, 12], JPS [6, 31] and GemStone [17, 40] support some form of software evolution using modified JVMs. Software evolution cannot be implemented on unmodified JVMs. 2.4 Reflective Interface for Java Metaobject protocols [23] o#er a principled way of extending the behavior of programs. Metaobjects can ....
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
....All objects reachable from persistent roots are automatically stored in persistent storage by the system the rest of the objects are garbage collected. Since Java has no persistence model built into it, many research systems have been proposed that add persistence to Java. These include PJama [3], JPS [6] GemStone J [17] and PSEJ [42] Of these, only PSEJ is JVM compatible. PSEJ uses the technique of bytecode rewriting. Bytecode rewriting has become an established technique for extending Java. But PSEJ has severe problems both in terms of its semantics and its performance. For example, ....
....system must provide a mechanism for upgrading the persistent objects. These upgrades involve 2 changes to the code implementing the persistent objects, as well as changes to the persistent objects themselves. Much research has been done on software evolution in persistent object systems. PJama [3, 12], JPS [6, 31] and GemStone [17, 40] support some form of software evolution using modi ed JVMs. Software evolution cannot be implemented on unmodi ed JVMs. 2.4 Re ective Interface for Java Metaobject protocols [23] o er a principled way of extending the behavior of programs. Metaobjects can be ....
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
....and implementation of a Java Persistent Store called JPS. JPS is an ecient distributed persistent Java system built on top of the Thor [LAC 96, CALM97] object oriented database. There are many other research and commercial e orts underway to add persistence to Java. These include PJama [AJDS96] which is being built by Sun and the University of Glasgow, the Persistent Storage Engine for Java [PSE] developed by ObjectStore, and GemStone J [Gem] developed by GemStone. Also, Oracle is planning to put Java into their next version of the Oracle8 database server, release 8.1. However, our ....
....have to depend on the paging mechanism of underlying operating system to manage the cache. One possible approach to integrate Java into Thor was to appropriately modify a standard Java interpreter and incorporate it into the client side of Thor. This is similar to the approach taken by the PJama [AJDS96] project. However, since interpreted code runs one to two orders of magnitude slower than compiled code [PTB 97, MMBC97] we abandoned this path. Another option was to build a Just In Time (JIT) compiler [JIT] into Thor s client side. Though this might have been the ideal solution in the ....
[Article contains additional citation context not shown here]
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for Persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Seventh International Workshop on Persistent Object Systems (POS7), Cape May, New Jersey, USA, 1996. Available at http://www.sunlabs.com/research/forest/COM.Sun.Labs.Forest.doc- .external www.papers.html.
....really movable objects does not carry too much weight. Java is very popular at the moment and thus there are a lot of running projects related to the Internet, World Wide Web and mobile agents. Projects like PJava (Glasgow Persistent CHAPTER 4. PROGRAMMING LANGUAGES FOR MOBILE PROGRAMMING 33 Java) [AJDS96] or Active Objects (Doug Lea) 6 will help to improve the language. Java is already strong in the sense of platform neutrality. Interpreters for most of the common platforms are available. Concurrency constructs are integrated into the language itself, which makes concurrent programming very easy ....
M.P. Atkinson, M.J. Jordan, L. Daynes, and S. Spence. Design Issues for Persistent Java: a type-safe, object-oriented, orthogonally persistent system. Technical report, University of Glasgow, February 1996.
....In this paper we report on the issues raised when investigating the ways of and developing the mechanisms for class evolution in PJama. The PJama project, a collaboration between Sun Microsystems Laboratories and the University of Glasgow, is building an orthogonally persistent platform for Java [1, 2]. PJama is the implementation of the programming language Java with mechanisms embedded into the runtime system that support indefinite lifetimes for a program s data. In fact, not all the data of some program, but only objects chosen by a PJama programmer persist. On the other hand, objects ....
M.P. Atkinson, L. Dayn`es, M.J. Jordan, and S. Spence. Design Issues for Persistent Java: A Type-Safe, Object-Oriented, Orthogonally Persistent System. In The Proceedings of the 7th International Workshop on Persistent Object Systems (POS 7), May 1996.
....callee class (which may or not be co located with the calling class) and (b) what access rights should be attached to the file parameters. 2) Developing really distributed applications with Java implies the integration of persistence in the language. Work is in progress towards that goal (e.g. Atkinson 96] In our current work, persistence is only achieved through the use of files. We intend to examine a possible extension of our protection environment to cover persitent Java objects. Despite its current limitations, we think that this work is a promising step toward the development of secure ....
M. P. Atkinson, M. J. Jordan, L. Dayns, and S. Spence, Design Issues for Persistent Java: a type-safe, object-oriented, orthogonally persistent system, to appear in Proc. of 7th Workshop on Persistent Object Systems (POS-7), 1996.
....is likely that it was the first such collector. However this lack means that at the least Almes techniques will have to be significantly extended to support concurrent collection for Jest. We are aware of two other efforts to provide generalpurpose persistence for Java: PJama (formerly Pjava) [4, 16, 6] and Gemstone J [8] PJama uses the same model of persistence by reachability that Jest does. However, their design goals are quite different. At the language level, PJama takes the conservative approach of not extending the syntax of Java or its bytecode representation. Instead, it provides ....
M. Atkinson, M. Jordan, L. Dayn`es, and S. Spence. Design Issues for Persistent Java: A Type-Safe, Object-Oriented, Orthogonally Persistent System. In the Pre-Proceedings of the 7th International Workshop on Persistent Object Systems (POS 7), May 1996.
....is how state is preserved; in general, there are 4 approaches to saving state in Java systems: 1. manually writing save and restore code in every application applet, 2. perform saving and restoration using (Java) serialisation, 3. providing persistence at the (Java) virtual machine level [2], and 4. providing persistence at the address space level. The first approach is the traditional solution to persistence: write flattening code by hand for every object class in the system. Whilst this is possible for simple data structures it becomes unmanageable in complex applications and has ....
....Internet. If this approach is to be followed, techniques such as Farkas OCTOPUS mechanism [4] or the use of weak pointers are also required. The next approach to saving state is to provide persistence at the (Java) virtual machine level. This is the approach followed by Atkinson s PJava group [2]. Whilst we have argued elsewhere that the last approach is better, this approach has many merits in the application domain described in this paper. It also addresses many of the shortcomings of the serialisation approach described above. Providing persistence at a level lower than the Java ....
Atkinson, M.P., et al. Design Issues for Persistent Java: a type safe, object oriented, orthogonally persistent system. in 7th International Conference on Persistent Object Systems. 1996: Springer-Verlag.
....of orthogonally persistent Java (OPJ) is the choice of means by which the Java language semantics are extended to include persistence. While Moss and Hosking [1996] outline a number of choices, the approach of modifying the underlying virtual machine has been dominant in the literature until now [Atkinson et al. 1996; Kutlu and Moss 1998; GemStone Systems 1999] In this paper we show that OPJ can be realized without modification to the Java virtual machine or compiler, and furthermore that while this approach is relatively simple, it can outperform an OPJ based on a modified Java virtual machine. After ....
....case is the use of a modified JVM with advanced introspection support. There are a number of ways in which standard Java semantics can be transparently extended, including: 2 modifying the virtual machine to directly implement the semantic extension either through the existing byte code set [Atkinson et al. 1996; GemStone Systems 1999] or via additional byte codes [Kutlu and Moss 1998] modifying the virtual machine to implement extended reflection capabilities through which semantic extensions can be implemented [Kutlu and Moss 1998] pre processing source code [Boyland and Catsagna 1997] ....
[Article contains additional citation context not shown here]
ATKINSON, M. P., JORDAN, M. J., DAYN ES, L., AND SPENCE, S. 1996. Design issues for Persistent Java: A type-safe, object-oriented, orthogonally persistent system. In R. CONNOR AND S. NETTLES Eds., Seventh International Workshop on Persistent Object Systems (Cape May, NJ, U.S.A., May 1996), pp. 33--47. Morgan Kaufmann.
....the notion of persistence from the start, such as Grasshopper [DRH 92] although object orientation is not used as the central paradigm of the system. Some systems add persistence to an existing object system by adding a layer that provides this property, as in the case of the Java platform [AJDS96] This software is in charge of the exchange between the instance area of the system and the secondary storage. The goal is not to modify the semantics and operation of the existing system. Main memory garbage collection of objects is one of the features of the existing system that is retained. ....
M.P. Atkinson, M.J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: a type-safe, object-oriented, orthogonally persistent system. In Seventh International Workshop on Persistent Object Systems, 1996.
No context found.
M.P. Atkinson, L. Dayns, M.J. Jordan, S. Spence. Design Issues for Persistent Java: a type-safe, object-oriented, orthogonally persistent system, Proceedings of the 7th International Conference on Persistent Object Systems, Cape May, New Jersey, May 1996.
No context found.
M.P. Atkinson, L. Dayns, M.J. Jordan, S. Spence. Design Issues for Persistent Java: a type-safe, object-oriented, orthogonally persistent system, Proceedings of the 7th International Conference on Persistent Object Systems, Cape May, New Jersey, May 1996.
....system, it may be crucial that its evolution subsystem can guarantee that any reasonable modification of persistent classes (schema) and, consequently, persistent objects, can be performed with minimum effort and without the necessity of rebuilding the whole database from scratch. PJama [1, 2, 10, 13] is an experimental persistent programming system for the Java programming language. It has much in common with object oriented database systems used together with Java. PJama is being developed as a collaborative project between Glasgow University and Sun Microsystems. For PJama, mechanisms are ....
M.P. Atkinson, L. Dayn`es, M.J. Jordan, and S. Spence. Design Issues for Persistent Java: A TypeSafe, Object-Oriented, Orthogonally Persistent System. In The Proceedings of the 7th International Workshop on Persistent Object Systems (POS 7), May 1996.
....2 and the Forest Research Group (FRG) at Sun Labs, 3 in October 1995. We initially envisaged PADRG building orthogonally persistent platforms (OPPs) and the FRG using them to build JP. The design and first prototype of PJama (we ll call it PJama 0:0 ) was completed by the PADRG by July 1996 [20, 16]. It was based on the JDK1.0 and used the architecture summarised in Figure 4.1.a. Durability and atomicity depended on Recoverable Virtual Memory [188] there was a buffer pool into which pages were brought and object addresses on disk (PIDs) were byte offsets from the start of the file. There ....
....Pool Standard GC Heap Cache Object Disk etc. Disk etc. Combined Object Cache and GCheap Store Adapter Sphere Java Application Modified JVM Figure 4. 1: Persistence Architectures used for Versions of PJama The original proposals for PJama included a flexible transaction mechanism [20, 64]( 10) The first experimental investigation of this was developed in summer 1998 by running JavaInJava (JIJ) 205] on PJama 0:1 , as PJama t . This gave full orthogonality but paid a high penalty in performance. Work is now underway to incorporate the flexible transaction model into the ....
[Article contains additional citation context not shown here]
M.P. Atkinson, M.J. Jordan, L. Daynes, and S. Spence. Design Issues for Persistent Java: A Typesafe, Object-oriented, Orthogonally Persistent System. In Connor and Nettles [51], pages 33--47.
No context found.
Malcolm P. Atkinson, Mick J. Jordan, Laurent Daynes, and Susan Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
No context found.
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
No context found.
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
No context found.
Malcolm P. Atkinson, Mick J. Jordan, Laurent Daynes, and Susan Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
No context found.
Malcolm P. Atkinson, Mick J. Jordan, Laurent Daynes, and Susan Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
No context found.
M. P. Atkinson, M. J. Jordan, L. Daynes, and S. Spence. Design issues for persistent Java: A type-safe, object-oriented, orthogonally persistent system. In Persistent Object Systems (POS), May 1996.
No context found.
ATKINSON,M.P.,JORDAN, M. J., DAYN ES, L., AND SPENCE, S. 1996. Design issues for Persistent Java: A type-safe, object-oriented, orthogonally persistent system. In R. CONNOR AND S. NETTLES Eds., Seventh International Workshop on Persistent Object Systems (Cape May, NJ, U.S.A., May 1996), pp.
First 50 documents
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC