2013/01/25

Farewell editorial

Filed under: Editorial — Oscar Nierstrasz @ 11:41

It is my great pleasure to welcome Jan Vitek as incoming Editor-in-Chief of JOT. Jan is a long-time contributor to the object-oriented community and is well known for his research in various aspects of programming languages and software engineering, more specifically in the areas of dynamic languages, mobile computation, transactional memory and embedded systems.

It has been nearly three years since Bertrand Meyer invited me to take over as Editor-in-Chief from Richard Wiener, who had done an amazing job of building up JOT’s readership and providing a steady flow of provocative articles on a variety of topics.
There have been mainly two kinds of changes to JOT since then. The first is visible to readers: JOT has a new look, with the web site being driven largely by meta-data. This makes it much easier to keep the web site up-to-date and consistent, and makes it easier to add new features. The second set of changes are visible to authors: the review process is formalized and more rigorous. Despite the added rigor, the review process is very competitive with other journals, with accepted papers typically appearing within six months to a year of initial submission.

In order to make this work, JOT relies on a dedicated team of associate editors (listed in the Masthead), and a large pool of anonymous reviewers who contribute their time to carefully reviewing submissions. In addition to regular articles, JOT has a strong tradition of publishing special issues and special sections of revised, selected papers from workshops and conferences related to object technology. These are prepared by invited editors, usually the PC Chairs of the original event. Finally there is nothing to review if there is not a steady stream of submissions. I would therefore like to sincerely thank all the authors, anonymous reviewers and associate and invited editors who contributed to JOT over the past three years!

Finally, I would like to offer my best wishes to Jan Vitek and encourage him to explore new ways for JOT to serve the OO community.

Oscar Nierstrasz
2013-01-25

2012/08/28

A short JOT status report

Filed under: Editorial — Oscar Nierstrasz @ 11:36

JOT is continuing with its policy of publishing issues as soon as new material is available. With this issue we have two regular papers: “DeepFJig — Modular composition of nested classes”, and “A Catalogue of Refactorings for Model-to-Model Transformations”, and we have two special sections, one with selected and expanded papers of ICMT 2011 (international Conference on Model Transformation, Guest editors: Jordi Cabot and Eelco Visser), and a second with selected and expanded papers from RefTest 2010 (Refactoring and Testing Workshop, Guest editors: Steve Counsell and Stephen Swift).

There is a healthy pipeline of submitted papers. 35 regular papers have been submitted so far this year (compared with a total of 60 last year, not counting special sections). 6 regular papers are currently in review, and another 3 are undergoing revision.

Several more special issues are currently in the works, in particular, one on IWMCP 2011 (Guest editors: Dimitris Kolovos and Davide Di Ruscio), and another on TOOLS Europe 2012 (Guest editors: Sebastian Nanz and Carlo Furia). Antonio Vallecillo, the Special Section editor is currently negotiating further sepcial sections, and would be glad to hear from you concerning further proposals.

Oscar Nierstrasz
August 2012

2012/04/25

The JOT format

Filed under: Editorial — Oscar Nierstrasz @ 18:28

In 2011, JOT experimented with a new, single-issue format, in which articles and special sections were published immediately upon acceptance of the final version. This scheme had the advantage that authors and readers did not have to wait for a backlog of previously scheduled issues before a paper would be published. The disadvantage is that it is harder to see when new material is published, since there is a new “issue” only once a year.

With this issue, JOT is reverting to a format with multiple issues throughout the year, however we will continue to publish new material “as soon as possible”. In practice this means that new articles will appear either in a current, open issue, or in the next scheduled issue. We plan to target four regular issues a year, and two to four further special issues dedicated to special topics.

Publishing material “as soon as possible” means that JOT will keep no backlog of papers for future issues. The risk for JOT is that an empty pipeline may lead to delays in publishing an issue. The advantage for the community is timely publication of new papers. As always, we call on you to submit previously unpublished research articles, surveys, tutorials, and technical notes on all aspects of object technology.

2011/01/31

JOT needs you!

Filed under: Editorial — Oscar Nierstrasz @ 22:28

Some of you may be wondering what has happened to JOT.

It seems that for the first time since its inception, JOT has missed a “deadline”, and no new issue appeared in January 2011.

Actually, JOT has moved to a new publication model in which there is no pipeline of accepted papers to be published.  Instead, accepted papers will appear as soon as possible after the final camera-ready copy is provided, whereas in the past, accepted papers sometimes had to wait up to a year to appear on-line.  The old pipeline of accepted papers and regularly scheduled issues of JOT expired with the November 2010 issue. Although the new system promises faster turnaround, the downside is that issues will no longer appear regularly as clockwork.

The current volume of JOT is now open. Articles will appear as they become available.
Although the new JOT promises faster publication for accepted papers, the evaluation process is tougher, while being more transparent (see the information for authors page).

Since the new procedures have been put in place, 43 papers have been submitted in 2010 for publication to JOT. Of these, 38 have been rejected for various reasons. Two papers are in the process of being revised, and a further 3 papers from 2010 are still under review. The average response time, excluding papers still in review was 24 days. The longest response time was 187 days (due to exceptional circumstances). By offering rapid feedback and fast, open-access publication to authors, we believe that JOT offers a highly credible and necessary service for the object-oriented community.

As of 2010, all current and prior JOT articles have Digital Object Identifiers, thus guaranteeing their archival nature. As of 2011, JOT is published by AITO, the steering association behind ECOOP, thus also guaranteeing JOT’s future existence.

JOT welcomes special sections on selected topics, including extended “best” papers of conferences, workshops and symposia. Several such special sections are planned for the coming weeks and months, specifically on:

JOT is changing, but we need your help to keep it going. We encourage our readers to submit mature research papers, state-of-the art surveys, empirical studies and best practice reports as regular technical articles, and reviews, conference reports, and technical notes as blog columns. We promise rapid feedback, quick publication turnaround and archival, open-access distribution.

2010/11/01

Long Live Metadata!

Filed under: Editorial — Tags: , , — Oscar Nierstrasz @ 17:37

This issue marks the end of the transition from the “old JOT” to the “new JOT” in a number of ways. The papers in this issue are the last of those previously accepted by the founding Editor-in-Chief, Richard Wiener. Starting in January 2011, JOT will move to  a format in which articles will be published as soon as possible after acceptance.  Although this change in policy will bring the risk that new articles will appear less regularly over time, we believe that both authors and the JOT readership will benefit from the more timely publication of articles. The new model will only work if JOT receives a steady supply of strong submissions, so the Editorial Board encourages you to submit mature research contributions for publication to JOT.

This issue also boasts several blog posts on OOPSLA/SPLASH 2010 and co-located events.  As with technical papers, future blog posts will appear as they are posted, and be added incrementally to the currently open JOT issue.  Please note that we are especially interested in volunteers who can provide solid blog posts covering events related to object technology.  Contact the Editor-in-Chief if you are willing to volunteer.

Another notable milestone is that all past JOT publications have now been assigned a permanent Digital Object Identifier.  DOIs are preferred over URLs as a more reliable way to refer to online publications.

Technically the most difficult part of assigning DOIs was to extract the metadata of all the JOT issues since 2002.  This was accomplished with the help of a Ruby script that crawled the JOT web site, attempting to recognize metadata in the HTML.  Since the format of JOT changed slightly over the years, and varied at times for special issues, it turned out that much of the script was dedicated to special cases.

Once the metadata was extracted, it could be used to generate a new web site. The current web site is entirely generated on the fly by PHP pages that are driven by the JOT metadata.  The Apache web server configuration hides most of the PHP behind restful URLs that make the dynamic web pages appear to be static (and which incidentally allows a static snapshot of the JOT web site to be easily mirrored).

Having metadata for all JOT issues available made it easy to provide new services.  BibTeX references, DBLP metadata, DOI submissions, JOT newsletters and search functionality were all relatively straightforward to provide.  The assignment of DOIs to all JOT articles has been made possible by the financial sponsorship of AITO.

The analysis of the old JOT web site revealed numerous errors and broken links.  These have been repaired and are less likely to occur with the new web site being generated from metadata.  Both Design-by-Contract and unit tests are used extensively to reduce the likelihood of errors being introduced as the metadata is updated with each new issue.

Since it was unclear at the beginning what metadata would be needed, extensibility was a key requirement.  Instead of using a database to store the JOT metadata, or to define (say) an XML schema to encode it, a simple text format was used based on the popular Markdown style.  This approach has the advantage of being both trivial to parse and trivial to extend.  The most important lesson from this experience is that simple approaches can help you to move quickly.

2010/08/26

Ten Things I Hate About Object-Oriented Programming

Filed under: Editorial — Tags: — Oscar Nierstrasz @ 17:25

Boy, I some days I really hate object-oriented programming.

Apparently I’m not the only one. In the immortal words of Edsger Dijkstra: “Object-oriented programming is an exceptionally bad idea which could only have originated in California.”

Well, I’m not normally one to complain, but I think it is time to step back and take a serious look at what is wrong with OOP. In this spirit, I have prepared a modest list of Ten Things I Hate About Object-Oriented Programming.

1. Paradigm

What is the object-oriented paradigm anyway? Can we get a straight story on this? I have heard so many different versions of this that I really don’t know myself what it is.

If we go back to the origins of Smalltalk, we encounter the mantra, “Everything is an object”. Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on. Clearly “Everything is an object” cannot be the essence of the paradigm.

What is fundamental to OOP? Peter Wegner once proposed that objects + classes + inheritance were essential to object-oriented languages [http://doi.acm.org/10.1145/38807.38823]. Every programming language, however, supports these features differently, and they may not even support them as built-in features at all, so that is also clearly not the paradigm of OOP.

Others argue convincingly that OOP is really about Encapsulation, Data Abstraction and Information Hiding. The problem is that some sources will tell you that these are just different words for the same concepts. Yet other sources tell us that the three are fundamentally different in subtle ways.

Since the mid-eighties, several myths have been propagated about OOP. One of these is the Myth of Reuse, which says that OOP makes you more productive because instead of developing your code from scratch, you can just inherit from existing code and extend it. The other is the Myth of Design, which implies that analysis, design and implementation follow seamlessly from one another because it’s objects all the way down. Obviously neither of these candidates could really be the OO paradigm.

Let’s look at other paradigms which offer a particular way to solve programming problems. Procedural programming is often described as programs = data + algorithms. Logic programming says programs = facts + rules. Functional programming might be programs = functions + functions. This suggest that OOP means programs = objects + messages. Nice try, but this misses the point, I think.

For me the point of OOP is that it isn’t a paradigm like procedural, logic or functional programming. Instead, OOP says “for every problem you should design your own paradigm”. In other words, the OO paradigm really is: Programming is Modeling

2. Object-Oriented Programming Languages

Another thing I hate is the way that everybody loves to hate the other guy’s programming language. We like to divide the world into curly brackets vs square brackets vs round brackets.

Here are some of the nice things that people have said about some of our favorite OOPLs:

“C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.”

It was Bjarne Stroustrup who said that, so that’s ok, I guess.

“Actually I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind.” — Alan Kay

“There are only two things wrong with C++: The initial concept and the implementation.” — Bertrand Meyer

“Within C++, there is a much smaller and cleaner language struggling to get out.” — Bjarne Stroustrup

“C++ is history repeated as tragedy. Java is history repeated as farce.” — Scott McKay

“Java, the best argument for Smalltalk since C++.” — Frank Winkler

“If Java had true garbage collection, most programs would delete themselves upon execution.” — Robert Sewell

But perhaps the best blanket condemnation is the following:

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” — Bjarne Stroustrup

3. Classes

Classes drive me crazy. That might seem strange, so let me explain why.

Clearly classes should be great. Our brain excels at classifying everything around us. So it seems natural to classify everything in OO programs too.

However, in the real world, there are only objects. Classes exist only in our minds. Can you give me a single real-world example of class that is a true, physical entity? No, I didn’t think so.

Now, here’s the problem. Have you ever considered why it is so much harder to understand OO programs than procedural ones?

Well, in procedural programs procedures call other procedures. Procedural source code shows us … procedures calling other procedures. That’s nice and easy, isn’t it?

In OO programs, objects send messages to other objects. OO source code shows us … classes inheriting from classes. Oops. There is a complete disconnect in OOP between the source code and the runtime entities. Our tools don’t help us because our IDEs show us classes, not objects.

I think that’s probably why Smalltalkers like to program in the debugger. The debugger lets us get our hands on the running objects and program them directly.

Here is my message for tool designers: please give us an IDE that shows us objects instead of classes!

4. Methods

To be fair, I hate methods too.

As we have all learned, methods in good OO programs should be short and sweet. Lots of little methods are good for development, understanding, reuse, and so on. Well, what’s the problem with that?

Well, consider that we actually spend more time reading OO code than writing it. This is what is known as productivity. Instead of spending many hours writing a lot of code to add some new functionality, we only have to write a few lines of code to get the new functionality in there, but we spend many hours trying to figure out which few lines of code to write!

One of the reasons it takes us so long is that we spend much of our time bouncing back and forth between … lots of little methods.

This is sometimes known as the Lost in Space syndrome. It has been reported since the early days of OOP. To quote Adele Goldberg, “In Smalltalk, everything happens somewhere else.”

I believe that the code-oriented view of today’s IDEs is largely to blame — given that OO code does not accurately reflect the running application, the IDE gets in our way instead of helping us to bridge the gap. Another reason I believe that Smalltalkers like to develop in the debugger is that it lets them clearly see which objects are communicating with which other objects. I am guessing that one of the reasons that Test-Driven Development is popular is that it also exposes object interactions during development.

It is not OOP that is broken — we just haven’t figured out (after over 40 years) how best to develop with it. We need to ask ourselves: Why should the source code be the dominant view in the IDE?

I want an IDE that lets me jump from the running application to the code and back again. (For a demonstration of this idea, have a look at the Seaside web development platform which allows you to navigate directly from a running web application to the editable source code. [http://seaside.st])

5. Types

OK, I admit it. I am an impatient guy, and I hate having to say everything twice. Types force me to do that.

I’m sure some of you are thinking — “Oh, how could you program in an untyped language. You could never be sure your code is correct.”

Of course there is no such thing as an “untyped” programming language — there are just statically and dynamically typed ones. Static types just prevent you from writing certain kinds of code. There is nothing wrong with that, in principle.

There are several problems, however, with types as we know them. First of all they tend to lead to a false sense of security. Just because your Java program compiles does not mean it has no errors (even type errors).

Second of all, and much more evil, is that type systems assume the world is consistent, but it isn’t! This makes it harder to write certain useful kinds of programs (especially reflective ones). Type systems cannot deal well with the fact that programs change, and that different bits of complex systems may not be consistent.

Finally, type systems don’t cope well with the fact that there are different useful notions of types. There is no one type system to rule them all. Recall the pain we experienced to extend Java with generics. These days there are many interesting and useful type systems being developed, but we cannot extend Java to accommodate them all. Gilad Bracha has proposed that type systems should not only be optional, in the sense that we should be able to run programs even if the type system is unhappy, but that they should be pluggable, meaning that we can plug multiple type systems into different parts of our programs. [http://bracha.org/pluggableTypesPosition.pdf] We need to take this proposal seriously and explore how our languages and development tools can be more easily adapted to diverse type systems.

6. Change

“Change is inevitable — except from a vending machine.” — Robert C. Gallagher

We all hate change, right? So, if everyone hates change, why do we all complain when things don’t get better? We know that useful programs must change, or they degrade over time.

(Incidentally, you know the difference between hardware and software? Hardware degrades if you don’t maintain it.)

Given that real programs must change, you would think that languages and their IDEs would support this. I challenge you, however, to name a single programming language mechanism that supports change. Those mechanisms that do deal with change restrict and control it rather than enable it.

The world is not consistent, but we can cope with that just fine. Context is a great tool for managing change and inconsistency. We are perfectly comfortable adapting our expectations and our behavior in our daily lives depending on the context in which we find ourselves, but the programs we write break immediately if their context changes.

I want to see context as a first-class concept in OO languages and IDEs. Both source code and running software should be able to adapt to changing context. I believe that many design patterns and idioms (such as visitors, and dependency injection) are simply artifacts of the lack of support for context, and would disappear if context were available as a first-class construct.

7. Design Patterns

Patterns. Can’t live with ’em, can’t live without ’em.

Every single design pattern makes your design more complicated.

Visitors. I rest my case.

8. Methodologies

“All methodologies are based on fear.” — Kent Beck

Evidently some of my students follow the Chuck Norris school of Agile Development:

“Chuck Norris pairs alone.”

“Chuck Norris doesn’t do iterative development. It’s right the first time, every time.”

“Chuck Norris doesn’t do documentation. He stares down the code until it tells him everything he wants to know.”

9. UML

Bertrand Meyer tells this story about always wondering why diagrammatic modeling languages were always so popular, until one day it hit him: “Bubbles don’t crash.” I believe his point is that OO languages are modeling languages. (AKA “All you need is code”)

There similarly appears to be something fundamentally wrong with model-driven development as it is usually understood — instead of generating code from models, the model should be the code.

By analogy, when FORTRAN was invented, it was sold as a high-level language from which source code would be generated. Nowadays we think of the high-level languages as being the source code.

I like to think that one day, when we grow up, perhaps we will think of the model as being the source code.

10. The Next New Thing

Finally, I hate the catchphrase: “Objects are not enough. We need …” Over the years we have needed frameworks, components, aspects, services (which, curiously, seems to bring us back to procedural programming!).

Given the fact that objects clearly never were enough, isn’t it odd that they have served us so well over all these years?

Conclusion?

25 years ago we did not expect object-oriented programming to last as a “new” phenomenon for so long. We thought that OO conferences like ECOOP, OOPSLA and TOOLS would last for 4 or 5 years and then fade into the mainstream. It is too soon to dismiss OOP as just being part of the mainstream. Obviously we cannot feel passionately about something that does not interest us. The fact that academic and industrial research is still continuing suggests that there is something deep and important going on that we do not yet fully understand.

OOP is about taming complexity through modeling, but we have not mastered this yet, possibly because we have difficulty distinguishing real and accidental complexity.

I believe that to make further progress we must focus on change and how OOP can facilitate change. After all these years, we are still in the early days of OOP and understanding what it has to offer us.

Oscar Nierstrasz
[Banquet speech given at ECOOP 2010. Maribor, June 24, 2010]

2010/07/28

Word template for JOT submissions is now available

Filed under: Announcement — Tags: , — Oscar Nierstrasz @ 14:45

This new template can be downloaded from the information for authors page. It mimics the LaTeX template as far as possible. To use the Word template you should install the Computer Modern fonts (instructions provided).

2010/07/08

Announcing JOT Volume 9, Number 4 (July 2010)

Filed under: Issue TOC — Tags: — Oscar Nierstrasz @ 11:07

JOT Volume 9, no. 4 (July 2010)

Editorial: Introducing the New JOT

By: Oscar Nierstrasz

HTML

Article: A Dependence Representation for Coverage Testing of Object-Oriented Programs

By: ESF Najumudheen, Rajib Mall, Debasis Samanata

Abstract

We propose a dependence-based representation for object-oriented programs, named Call-based Object-Oriented System Dependence Graph (COSDG). Apart from structural features, COSDG captures important object-oriented features such as class, inheritance, polymorphism, and dynamic binding. Novel features of COSDG include details of method visibility in a derived class, and different types of method call edges to distinguish between various calling contexts — simple, inherited, and polymorphic. We also propose an algorithm for the construction of COSDG, and subsequently explain its working with an example. COSDG has been developed primarily to aid test coverage analysis. However, it can be used in a variety of other software engineering applications such as program slicing, software re-engineering, debugging, etc.

PDF

Article: A UML and Colored Petri Nets Integrated Modeling and Analysis Approach using Graph Transformation

By: Elhillali Kerkouche, Algeria Allaoua Chaoui, El Bay Bourennane, Ouassila Labbani

Abstract

Nowadays, UML is considered to be the standardized language for object-oriented modeling and analysis. However, UML cannot be used for automatic analyses and simulation. In this paper, we propose an approach for transforming UML statechart and collaboration diagrams to Colored Petri net models. This transformation aims to bridge the gap between informal notation (UML diagrams) and more formal notation (Colored Petri net models) for analysis purposes. It produces highly-structured, graphical, and rigorously-analyzable models that facilitate early detection of errors such as deadlock and livelock. The approach is based on graph transformations where the input and output of the transformation process are graphs. The meta-modeling tool AToM3 is used. A case study is presented to illustrate our approach.

PDF

Article: Extending Scala with Database Query Capability

By: Miguel Garcia, Anastasia Izmaylova, Sibylle Schupp

Abstract

The integration of database and programming languages is difficult due to the different data models and type systems prevalent in each field. We present a solution where the developer may express queries encompassing program and database data. The notation used for queries is based on comprehensions, a declarative style that does not impose any specific execution strategy. In our approach, the type safety of language-integrated queries is analyzed at compile-time, followed by a translation that optimizes for database evaluation. We show the translation total and semantics preserving, and introduce a language-independent classification. According to this classification, our approach compares favorably with Microsoft’s LINQ, today’s best known representative. We provide an implementation in terms of Scala compiler plugins, accepting two notations for queries: LINQ and the native Scala syntax for comprehensions. The prototype relies on Ferry, a query language that already supports comprehensions yet targets SQL:1999. The reported techniques pave the way for further progress in bridging the programming and the database worlds.

PDF

Article: REquirements, Aspects and Software Quality: the REASQ model

By: Isi Castillo, Francisca Losavio, Alfredo Matteo, Jørgen Bøegh

Abstract

Object-oriented analysis and design have been more concerned with system functionality, neglecting non functional aspects; the result is code entanglement, difficult to maintain, contradicting main principles of object orientation. Aspect Oriented Software Development (AOSD) proposes the early specification of non functional requirements. However, a standard and homogenous vision of the AOSD terminology is still missing. The goal of this work is to integrate AOSD concepts, classic requirements engineering notions, and the new standard ISO/IEC 25030 on software quality requirements.The main result of this study is the REASQ (REquirements, Aspects and Software Quality) conceptual model, expressed in UML. All the modeling concepts are formalized into three related ontologies, representing the ambits of aspect-orientation, software quality and requirements engineering. The ontologies can be used as an umbrella to specify quality requirements in aspect-oriented engineering processes.

PDF

Article: Using a Situational Method Engineering Approach to Identify Reusable Method Fragments from the Secure TROPOS Methodology

By: Graham Low, Haris Mouratidis, Brian Henderson-Sellers

Abstract

Situational method engineering (SME) has as a focus a repository of method fragments, gleaned from extant methodologies and best practice. Using one such example, the OPF (OPEN Process Framework) repository, we identify deficiencies in the current SME support for security-related issues in the context of agent-oriented software engineering. Specifically, theoretical proposals for the development of reusable security-related method fragments from the agent-oriented methodology Secure Tropos are discussed. Since the OPF repository has already been enhanced by fragments from Tropos and other non-security-focussed agent-oriented software development methodologies, the only method fragments from Secure Tropos not already contained in this repository are those that are specifically security-related. These are identified, clearly defined and recommended for inclusion in the current OPF repository of method fragments.

PDF

Review: Succeeding With Agile: Software Development Using Scrum, by Mike Cohn

By: Charles Ashbacher

HTML

2010/06/30

Introducing the new JOT

Filed under: Editorial — Tags: — Oscar Nierstrasz @ 09:54

This issue of JOT marks a number of changes in the goals, process, appearance and format of the Journal of Object Technology.

The object-oriented research community needs a strong archival journal commanding the right level of scientific respect. JOT, the Journal of Object Technology, published by Bertrand Meyer at ETH and edited by Richard Wiener since 2002, is the spiritual successor to JOOP, the Journal of Object-Oriented Programming. JOT has combined aspects of a traditional scientific journal with scientific-magazine-style features such as columns. In the absence of any other reference publication in the field, a group of researchers including Bertrand Meyer and myself has taken the initiative to devise a new, expanded formula for JOT, which will emphasize the research orientation and instill high standards of refereeing, while retaining some of the industry-oriented features that have sustained the success of JOT over the past eight years.

Periodic and regular rotation of staff is important to keep a volunteer organization healthy. Accordingly, this issue of JOT introduces a new editorial board, mandated to establish the highest scientific quality for JOT research contributions by actively soliciting strong submissions and by applying rigorous review standards to submitted papers. Terms for associate editors and the editor-in-chief are normally two years, renewable once. A separate steering committee now oversees the editorial process and all other strategic and management decisions.

The JOT submission and review process has been thoroughly revised to ensure full transparency, high standards of refereeing, and rapid turnaround. Papers judged to be within scope will normally be reviewed by three expert referees, and a final decision should be given within 3 months. During 2010, JOT will be emptying its pipeline of accepted papers so that, starting January 2011, papers will be published as soon as the final camera-ready version is available. In a change with JOT’s former policy, authors will retain their copyright, instead signing a simplified copyright agreement. JOT also plans to introduce Digital Object Identifiers for all accepted research contributions. AITO (Association Internationale pour les Technologies Objets) has agreed to sponsor JOT, thus guaranteeing the future of the web site and the digital object identifiers.

The JOT format will be modified to clearly distinguish peer-reviewed research contributions from reviews, columns, and other non-research contributions. Instead of publishing all contributions in both HTML and PDF, research contributions will be published only in a newly-design PDF format, suitable for printing as well as on-line viewing, whereas non-research contributions will appear exclusively on-line. In additional to regular research papers, JOT will also explicitly welcome state-of-the-art surveys and tutorials for emerging research fields. These contributions will undergo the usual peer-review process for research contributions.

The JOT web site has also been completely redesigned to be generated from metadata describing individual articles. This strategy eliminates the need for manual authoring of web pages for articles and issues, thus reducing the potential for errors while facilitating the gradual integration of new features into the web site, such as the automatic generation of BiBTeX entries for published articles. A separate WordPress blog is also being introduced with this issue, to host all non-research contributions (such as this editorial) and JOT announcements. Postings will automatically appear in the JOT RSS and Twitter feeds, thus providing more modern mechanisms to notify subscribers of new content and offering more convenient means to offer timely feedback.

I believe that JOT is well placed to establish itself as a unique open-access archival journal dedicated to all aspects of object technology, but we need your help and contributions to achieve this. An important milestone will be to have JOT listed in the best known indexes, such as the ISI Web of Science, but the selection process can be time-consuming. JOT can only establish itself as an “A” journal through a concerted community effort.

There are several things you can do to help. First, subscribe to JOT (by email, RSS or Twitter) and spread the word. Second, cite JOT publications in your work. Third, contribute full or expanded versions of your best research results to JOT, and encourage colleagues to do the same. We especially welcome expanded versions of high quality conference and workshop contributions. Finally, we also welcome timely and topical non-research contributions to the JOT blog to raise JOT’s visibility.

Oscar Nierstrasz

2010/06/07

Welcome to the JOT Blog

Filed under: Announcement — Oscar Nierstrasz @ 12:11

The Journal of Object Technology is a peer-reviewed, open-access journal dedicated to the timely publication of previously unpublished research articles, surveys, tutorials, and technical notes on all aspects of object technology. This blog complements the main web site with editorials, reviews, technology updates, and other news items related to object technology.

Powered by WordPress