Frequently Asked Questions

  1. Can I freely use Tentackle in my applications?
  2. What about the "k" in Tentac(k)le?
  3. Yet another framework?
  4. What's the status of the project?
  5. What's so unique about Tentackle?
  6. How is Tentackle related to Generative Programming?
  7. Why not POJO?
  8. How many classes do I have to learn?
  9. And the performance?
  10. How does Tentackle compare to EJB?
  11. Why is Active Record so uncommon to Java?

Can I freely use Tentackle in my applications?

Yes! Tentackle is Open Source according to the LGPL, the GNU LESSER GENERAL PUBLIC LICENSE.

What about the "k" in Tentac(k)le?

The short story is: when we decided to go Open Source with "Tentacle", the domain was already in use. So we made the best of it and simply added a k.

Yet another framework?

First of all, Tentackle was never meant to become a framework. It wasn't meant to become Open Source as well. We just needed something for our Java projects, but there was nothing comparable available, neither open nor closed source. So we began to develop the things we needed. Several years later, there still wasn't anything comparable available -- at least, up until today, we never heard about something similar. Anyway, at some point the people involved in our projects began to talk about "the framework". And here it is.

What's the status of the project?

We've got several Tentackle-based applications in production already, for years. There are even 24x7 technical apps running in production plants. The code can be considered as stable and robust. Of course, there are constantly new features cropping up and in order to get the code "Open Source"-ready, we did some refactoring to the Open Source trunk.
What needs to be done -- you guessed it -- is some more in-depth documentation. We've used Tentackle in our projects and we didn't plan to go Open Source with it. As a consequence, there is not much documentation available besides the API javadocs.
At the moment we are working on a tutorial which will cover most of Tentackle's goodies. Although the tutorial isn't finished yet, you can try out what's available so far. Please give us some feedback!

What's so unique about Tentackle?

Tentackle is a Java-framework for fat-client multiuser n-tier enterprise applications. This is the kind of software companies are running their daily business with. While the well-known software tycoon never neglected the desktop and continuously improved its technology, the Java community was more or less focusing on the web during the last years. Sure, you can use an EE-container as a middle tier server for Swing-clients, but you have to develop the client/server-layer from scratch, you still don't have a client-side object cache, and even simple tasks like lazy loading require a lot of work(arounds). With Tentackle you get all that out of the box -- and a lot more!
The goal of Tentackle is not to introduce new shiny design patterns, but to reduce the development effort, time to market and -- as a result -- the cost as effectively as possible. At the same time, the applications run faster, the amount of source code is reduced considerably, is better readable, easier to maintain and of better quality. When developing a typical business application with Tentackle, you don't need to extend standard classes for trivial things anymore or write generic code that is not related to your specific application. Whether you need the datatype for money, its Swing bean, a navigatable object tree, an easy to use o/r-mapping, a decent security model, a business report with 5 cascaded subtotals, or a distributed server topology for a worldwide operating company: it's all there! Because Tentackle addresses the requirements of typical business applications as a whole, it provides a truly integrated environment on top of Java SE. For example, if you change the width of a database column in your data model, the corresponding Swing beans will automatically get their maxColumns-attribute adapted as well. It's agile! It's fast! It's easy!

How is Tentackle related to Generative Programming?

Tentackle follows a pure object oriented approach and was designed with generative programming in mind from the very beginning. "Pure OO" means that there is no bytecode instrumentation, no XML configuration, no reflection-based generation of code behind the scenes. Everything is in the source. Everything is Java.
While this seems straightforward, it has its drawbacks when it comes to things like O/R-mapping, because manually extending classes and overriding methods can become a tedious and errorprone job, especially in larger applications. This is where the Wurbelizer comes in. It generates the code for you whenever possible. For example, the Java code for the O/R-layer is generated by the Wurbelizer from the data model. It is just as you would have written it manually, but at a fraction of your precious time.

Why not POJO?

Unlike many other frameworks, Tentackle does not follow the POJO-pattern. One reason has already been mentioned: persistence with POJOs requires some "javoodoo" behind the scenes. However, there is more. One of Java's really nice concepts is "create, use and forget". In business applications dealing with database objects, this basically means: begin a transaction, load and/or create objects, do something with the objects, save and commit (or rollback) -- and forget. The rest is up to the garbage collector, provided that there are no further references to the objects! This is the reason why Tentackle Application Database Objects refer to a Database Context as opposed to the POJO-approach where some entity- or session-manager refers to the (attached POJO) objects. With POJOs you have to explicitly detach the objects in order to release memory. But what about lazy loading? By nature, desktop applications use lazy loading heavily. Consider a navigatable object tree. If and which node the user expands cannot be predicted. Loading in advance would be far too expensive (besides it's sometimes hard to tell where to stop preloading). Furthermore, you cannot leave the objects attached forever, as this would eat up all memory. You have to attach and detach explicitly for each lazy load! With Tentackle, however, you don't need to worry about such inconveniences. As each object carries a reference to the database context, it can lazily load other objects within its context. If the user closes an object tree, it's just that: close and forget. The rest is done by the GC. This is Java!

How many classes do I have to learn?

O/R-mapper, middle tier server, rich Swing-based GUI, ACL-based security model, reporting, application lifecycle, and much more, doesn't that end up with thousands of classes to learn?
The opposite is true! Tentackle is very slim, because it's not bloated with code dealing with runtime configuration issues. It does not need such configuration because it's based on a generative programming approach. By this, it can be kept small and generic. We're talking about no more than 400 classes.
You don't believe it? Try out the tutorial.

And the performance?

You will be surprised! Besides the fact that Tentackle is very slim and compact, one of the reasons for its high performance is its fast distributed object cache. Desktop clients do a lot of selects for displaying data, scrolling through lists, navigating in trees, updating the GUI and so on. All those selects are read-only, i.e. non-transactional. Only very few (the business logic) require transactions and, in principle, cannot use cached objects. Knowing that a cache speeds up an application primarily by reducing the number of roundtrips between the client and the server, where do you think the cache should be located? In the server, as with EE-containers, or in the client? You guessed it: in the client, for sure! With Tentackle, the middle tier server not only runs the transactions but it efficiently supports the clients in order to keep their caches up to date. As a result, the roundtrips between the database backend, the server and the clients are reduced to a minimum. All that is completely transparent to your application's code. You don't even need to know that there is a server at all. In fact, Tentackle applications run with or without a server (2- or 3-tier, more precise: n-tier). It's just a matter of changing a small config file.

How does Tentackle compare to EJB?

As a developer familiar with the Java-EE platform (formerly J2EE) and after having studied the tutorial, you probably wonder how Tentackle's architectural concepts compare to those of Enterprise Java Beans. Is life possible without entity beans, session beans or entity managers?
Yes and no! ;-)
Yes, because as a Tentackle developer you don't care about all that. No, because there are such things. They just have different names:
Besides active record, there is another fundamental difference to EJB: because AppDbObjects are remotable and are always attached to a logical connection, Tentackle applications are able to run in 2- or 3-tier mode without any modification. In other words: you get the middle-tier capability for free. You don't need to write a single session bean (or even boring DTOs as in EJB2). Just design your entities, your business logic and run your application in whatever setup you like. You can even use your application as a web-backend. It's really that simple!

Why is Active Record so uncommon to Java?

Active Record (AR) is not a new design pattern but has attracted new attention primarily in context with the Rails framework, which is written in Ruby. Rails implements AR by using the dynamic features of the Ruby-language. If, for example, the method find_by_name is undefined, it will be generated at runtime according to the data model and some conventions about how to map entities to database tables and columns. Java, however, is not a dynamic language and such functionality is much harder to implement. Either you develop some magic javoodoo with reflection, special classloaders compiling generated source code on-the-fly and bytecode instrumentation to manipulate existing classes, or you go the traditional OOP way with polymorphism and overriding methods. At first glance both solutions don't seem very attractive. The first because it's a weird and tricky workaround (Java developers usually don't like hidden and invisible source code), and the second because it requires a lot of manually written code to override and/or implement methods according to the data model. As a consequence, active record frameworks for Java are rare.
Tentackle, however, is different because it compensates the drawbacks of static languages with Generative Programming (GP). In fact, it works pretty similar to the dynamic approach, except that the code is generated at build-time and not at runtime. This is done with the help of the Wurbelizer, a special code generator that modifies the code right in place according to the model. As a result, the developer does not need to write the model-specific code manually. This is one of the reasons why application development with Tentackle is so efficient and fast.