Group items tagged

Lucene is an Open Source, mature and high-performance Java search engine. It is highly flexible, and scalable from hundreds to millions of documents. Luke is a handy development and diagnostic tool, which accesses already existing Lucene indexes and allows you to display and modify their content in several ways: * browse by document number, or by term * view documents / copy to clipboard * retrieve a ranked list of most frequent terms * execute a search, and browse the results * analyze search results * selectively delete documents from the index * reconstruct the original document fields, edit them and re-insert to the index * optimize indexes * and much more... Recent versions of Luke are also extensible through plugins and scripting. I started this project because I needed a tool like this. I decided to distribute it under Open Source license to express my gratitude to the Lucene team for creating such a high-quality product. Lucene is one of the landmark proofs that Open Source paradigm can result in high-quality and free products.

"AtomServer is a generic data store implemented as a RESTful web service. It is designed as a GData-style Atom Store. It is based on the following concepts and protocols; REST. REST is a design pattern. It's not a technology like SOAP or HTTP. REST is a proven design pattern for building loosely-coupled, highly-scalable applications. There are important benefits to sticking to the REST design pattern; Simple. REST is incredibly simple to define. There are just a handful of principles and well defined semantics associated with it. Scalable. REST leads to a very scalable solution by promoting a stateless protocol and allowing state to be distributed across the web. Layered. REST allows any number of intermediaries, such as proxies, gateways, and firewalls. Ultimately REST is just a web site, albeit one that adheres to a design pattern, so one can easily layer aspects such as Security, Compression, etc. on an as needed basis. Atom. Fundamentally, Atom is an XML vocabulary for describing lists of timestamped entries. These entries can be anything, although because Atom was originally conceived to replace RSS, Atom lists are Feeds, and the items in the lists are Entries. Atom is a RESTful protocol. AtomServer stands on the shoulders of giants. It is built on top of several open source projects - most notably, Apache Abdera (a Java-based Atom Publishing framework) and Spring. AtomServer is an Atom Store. Thus, it requires a relational database to run. AtomServer currently supports; PostgresSQL, SQLServer, and HSQLDB. Using HSQLDB, AtomServer requires zero configuration and can run out-of-the-box. While this configuration is suitable for many applications, those that see significant load will likely require a database with better transactional semantics, such as PostgreSQL. AtomServer is easy to use. It deploys as a simple WAR file into any Servlet container. Or alternately, can be used out-of-the-box as a standalone server, running with

"The NetKernel Resource Oriented Computing (ROC) platform separates architecture from code. With ROC you can compose your architectural design independently from implementation code. By keeping the details of code separate from high-level information architecture you gain: freedom of choice in implementation language rapid click-fit compositional development long-term evolvable solutions Threading and scheduling is managed by the microkernel so your code execution is efficiently optimised with linear scaling on multi-core without the need to learn new languages. Something brand-new also comes from separating architecture and code. NetKernel provides system-wide caching of every area of your system. For free. No configuration. NetKernel learns what information is reusable and reuses it. This makes NetKernel systems fast. Very fast."

The objective of Eclipse Scout is to substantially reduce the development time needed for SOA and Java-conforming business software. Scout includes: an application model, a reference implementation, proven development functions and a comprehensive tool: the Scout SDK.

The packaging type eclipse-repository was originally introduced for building products that can be updated with p2 (cf. TYCHO-188). This requires the following build results: a p2 repository which contains the product IU, and a zip file with the installed product. (Although this is technically no longer needed since the Update Manager was replaced by p2, zip files are still the primary way to distribute Eclipse/RCP installations.) For ease of implementation, this was done in the same packaging type eclipse-repository. In the meantime, eclipse-repository has gained in capabilities (in particular through TYCHO-491), making it difficult for users to choose the right packaging types. This page lays out the mid-term plan of how we want to build products, update site categories, and p2 repositories in Tycho. It also contains a few details how the transition todays (0.11.0) packaging types (eclipse-repository, eclipse-application, eclipse-update-site) to the new types eclipse-repository and eclipse-product.

iPOJO is a service component runtime aiming to simplify OSGi application development. It natively supports ALL the dynamism of OSGi. Based on the concept of POJO, application logic is developed easily. Non-functional properties are just injected in the component at runtime. iPOJO strength points are : components are developed as POJO, nothing else is required ! the component model is extensible, so feel free to adapt it to your needs the standard component model manages service providing and service dependencies, and so can require any other OSGi services iPOJO manages the component instance lifecycle and the environment dynamics as it has never been possible iPOJO provides a powerful composition system to create highly dynamic applications iPOJO supports annotations, XML or Java-based API to define the component

"JMockit allows developers to write unit/integration tests without the testability issues typically found with other mocking APIs. Tests can easily be written that will mock final classes, static methods, constructors, and so on. There are no limitations. The JMockit mocking API is simple, consistent, and minimal. There are no special methods or annotations that need to be used in test code, apart from those that really make sense. In general, the use of JMockit APIs for mocking leads to test code that is better structured and more readable. "

Google's voice search feature is likely to enthrall anyone with an Android-powered smartphone or an iOS device that searches through the Google app.

If you are not aware of cloud computing , then don't worry!

Does it all make sense now? Do you know how to solve every problem? Probably not, but when it comes right down to it, using Java EE can be even simpler than using Spring, and take much less time. You just have to find the right guides and the right documentation (which is admittedly a severe sore-spot of Java EE; the documentation is still a work in progress, but is getting much better, save blogs like this one.) You have to turn to a vendor like JBoss, or IBM in order to get the use-case driven documentation you need, and they do have documentation, it's just a matter of finding it. Seam 3 in particular strives to give extensive user-documentation, hopefully making things much simpler to adopt, and easier to extend. The main purpose of this article was not to bash Spring, although I may have taken that tone on occasion just for contrast and a little bit of fun. Both Spring and Java EE are strongly engineered and have strong foundations in practical use, but if you want a clean programming experience right out of the box - use Java EE 6 on JBoss Application Server 6 - JBoss Tools - and Eclipse. I will say, though, that the feeling I've gotten from the Spring forums vs the Java EE forums, is that there are far many more people willing to help you work through Java EE issues, and more available developers of the frameworks themselves to actually help you than there are on the Spring side. The community for Java EE is much larger, and much more supportive (from my personal experience.) In the end, I did get my application migrated successfully, and despite these issues (from which I learned a great deal,) I am still happy with Java EE, and would not go back to Spring! But I do look forward to further enhancements from the JBoss Seam project, which continue to make developing for Java EE simpler and more fun. Don't believe me? Try it out. Find something wrong? Tell me. Want more? Let me know what you want to hear.

JDBC 4.0 Enhancements in Java SE 6 Java Platform, Standard Edition (Java SE) version 6 (code name Mustang), is currently in its second beta release and is scheduled to be delivered in October of this year. Java SE 6 includes several enhancements to the Java Database Connectivity (JDBC) API. These enhancements will be released as JDBC version 4.0. The main objectives of the new JDBC features are to provide a simpler design and better developer experience. This article provides an overview of the JDBC 4.0 enhancements and what benefits they offer to enterprise Java developers. We will explore the new JDBC features with the help of a sample loan processing application using Apache Derby as the back-end database.