Here is a great example why IntelliJ will always win. With the latest milestone, you can now find usages (references in Eclipse lingo) and see them as a context popup. Here is how it looks like:
As someone who uses this feature all the time, this is an amazing time saver (instead of showing it in a different view). IntelliJ is simply swamped with such small features.
Just read an excellent article over at devx called Multi-core Mythbusters. The article is very good at explaining in layman’s terms the need for scalability. The article title is a bit misleading as it even talks about scaling out an application across machines (or for that purpose, JVM instances). What really hit the mark for me is this:
Although it is true that Java app servers provide a degree of concurrency, many Java developers are under the mistaken impression that the app server will simply take care of all of their scalability needs.
This is probably one of the most cherished viewpoints of the J2EE server space. As such, it is one of the most tenacious in the face of arguments to the contrary. Fortunately, it doesn’t take a great deal of logical reasoning to see its inherent flaws. The belief begins with the basic assumption that when a particular J2EE application does not scale, it is due to the CPU not running fast enough. For most of today’s applications, however, the CPU is not being kept busy. A large part of the application server execution time is spent transmitting data back and forth across components, taking out locks, or waiting for locks to be released. Spending some quality time with a profiler can show you just how much time your application spends on these tasks, which cannot benefit from a faster CPU.
This is a great explanation of why application server mostly simply do not cut it. I have been talking for some time now about the need for some sort of a “Next Generation App Server”. The next generation part in my case revolves around how to write scalable application in a simplified manner.
One of the main problems with current application servers is the fact that there are many different moving parts such as JMS, EJB, and JPA without tight integration between them. Another main problem is the fact that JEE missed an important aspect for writing scalable application, which is the data grid.
Now, lets assume we live in a perfect world. We would have all this moving/missing parts handled by the same library. We would have the ability to store our domain model within a data grid, be able to register and receive events due to changes of the domain model within the data grid (allowing us to have an EDA / ESB like support), and be able to perform parallel operations (ala Map Reduce) simply using our domain model.
In such a scenario, our clients will either work in an embedded mode with our data/event grid, or work with it remotely and be able to perform all the operations on a single system image which is our grid (such as write and take objects from the gird, register for events, and so on). They could even create a running window over a subset of the data. This clients will probably be either RIA or fat clients.
To wrap the story, it would be great if we can have the same, simple deployment model that application servers allow us, with the addition of smart relocation and service level definitions for different bundles.
Though naturally this is not a perfect world, GigaSpaces is certainly heading in the right direction (in my neutral opinion ;) ). The latest release, with OpenSpaces (which your not so humble blogger was responsible for) and GigaSpaces core functionality, we are now very close at realizing such an architecture.
There is no doubt, in my mind, that this type of architecture will be part of any future applications, as explained so eloquently in the devx article. I bet this is how Hibernate/TopLink/Kodo felt before JPA. A storm is coming…
This is just too funny:
I really like the part where the girl asks “can we thin out the line?”, and the other guy says dismissively: “No”.
This also got me thinking about similar projects in Javaland, JSF anyone :)? What is your MS Paint in Javaland?
I am pleased to announce the release of Compass 1.2 M3. Compass 1.2 M3 includes several major features and considered to be a major and last milestone within the 1.2 release lifecycle (RC is next). Some of the major features include:
A “native” integration with OpenJPA allowing to configure Compass within a persistence unit and have OpenJPA start Compass up and expose both mirroring (changes made through OpenJPA are mirrored to the search engine though Compass) and indexing (the ability to execute parallel index operation to reindex the whole database based on Compass and OpenJPA mappings). See here for more details.
Compass now supports polymorphic queries, allowing to execute queries that match a concrete alias/class and all its sub classes / extended aliases.
Compass also has improved range and exact queries when using numbers and dates (actually, on any custom converter as well). Executing queries such as: “age:1″ or “age:[1-90]” will automatically work (with proper padding format within the mapping). See here for more details.
Dates now support a relative now format, allowing to execute queries such as: “publishDate:now-10days”. See here for more details.
Compass comes with better support for Lucene 2.2, including pluggable Index deletion policy (allows for storing history of commit points) including built in support for several index deletion policies. See here for more information.
Compass now exposes Lucene “more like this” query capabilities in very simple API. A simple compassSesion.queryBuilder().moreLikeThis(”a”, “1″).toQuery().hits() can be executed to perform a more like this on the “all” property (remember to have term vector set to yes on the all property) that will match things like the Resource identified by alias “a” with id “1″.
Compass now supports the ability to define a local cache per sub index. This allows to configure certain sub indexes to be stored in memory for faster searching, or have a local file system cache when working with Jdbc. The new local cache mechanism fully supports several clients connecting to the same index storage location. See here here for more details.
An improved JPA device allowing to configure custom indexers with default implementation including specific ones for OpenJPA and Hibernate for better performance (still trying to figure out how to do that in Toplink and being too lazy too look at the source code :), see this Toplink forum thread ).
A complete new Hibernate Gps Device allowing for several custom simpler extension points such as indexer, custom query provider, … . Compass comes with two default indexer implementations including pagination and scrollable (better performance, though latest Hibernate has a memory leak that will be fixed in the next minor version - 3.2.5). See here for more details.
Deprecated Hibernate2GpsDevice and Hibernate3GpsDevice still exists within Compass codebase, thought they have been refactored into a different package (org.compass.gps.device.hibernate.dep).
A lot of this features are major features with Compass. I will blog more about each one in separate posts. I am really excited about the more native integration with OpenJPA, and would like to thank Patrick Linskey for doing an amazing job in the integration effort. Suggestion or enhancements to OpenJPA to allow for such an integration were done faster then I could ask for them, amazing!.
My name is Shay Banon, the founder of Compass, a Java Search Engine framework and work as a System Architect for GigaSpaces.
You can reach me at: kimchy at gmail.com