CDI AOP Tutorial: Java Standard Method Interception Tutorial - Java EE
This article discusses CDI based AOP in a tutorial format. CDI is the Java standard for dependency injection (DI) and interception (AOP). It is evident from the popularity of DI and AOP that Java needs to address DI and AOP so that it can build other standards on top of it. DI and AOP are already the foundation of many Java frameworks. CDI is a foundational aspect of Java EE 6. It is or will be shortly supported by Caucho's Resin Java Application Server, Java EE WebProfile certified, IBM's WebSphere, Oracle's Glassfish, Red Hat's JBoss and many more application servers. CDI is similar to core Spring and Guice frameworks. Like JPA did for ORM, CDI simplifies and sanitizes the API for DI and AOP. If you have worked with Spring or Guice, you will find CDI easy to use and easy to learn. If you are new to AOP, then CDI is an easy on ramp for picking up AOP quickly, as it uses a small subset of what AOP provides. CDI based AOP is simpler to use and learn. One can argue that CDI only implements a small part of AOP—method interception. While this is a small part of what AOP has to offer, it is also the part that most developers use. CDI can be used standalone and can be embedded into any application. Here is the source code for this tutorial, and instructions for use. It is no accident that this tutorial follows many of the same examples in the written three years ago. It will be interesting to compare and contrast the examples in this tutorial with the one written three years ago for Spring based AOP. Design goals of this tutorial This tutorial is meant to be a description and explanation of AOP in CDI without the clutter of EJB 3.1 or JSF. There are already plenty of tutorials that cover EJB 3.1 and JSF (and CDI). We believe that CDI has merit on its own outside of the EJB and JSF space. This tutorial only covers CDI. Repeat there is no JSF 2 or EJB 3.1 in this tutorial. There are plenty of articles and tutorials that cover using CDI as part of a larger JEE 6 application. This tutorial is not that. This tutorial series is CDI and only CDI. This tutorial only has full, complete code examples with source code you can download and try out on your own. There are no code snippets where you can't figure out where in the code you are suppose to be. So far these tutorials have been well recieved and we got a lot of feedback. There appears to be a lot of interest in the CDI standard. Thanks for reading and thanks for your comments and participation so far. AOP Basics For some, AOP seems like voodoo magic. For others, AOP seems like a cure-all. For now, let's just say that AOP is a tool that you want in your developer toolbox. It can make seemingly impossible things easy. Aagin, when we talk about AOP in CDI, we are really talking about interception which is a small but very useful part of AOP. For brevity, I am going to refer to interception as AOP. The first time that I used AOP was with Spring's transaction management support. I did not realize I was using AOP. I just knew Spring could apply EJB-style declarative transaction management to POJOs. It was probably three to six months before I realized that I was using was Spring's AOP support. The Spring framework truly brought AOP out of the esoteric closet into the main stream light of day. CDI brings these concepts into the JSR standards where other Java standards can build on top of CDI. You can think of AOP as a way to apply services (called cross-cutting concerns) to objects. AOP encompasses more than this, but this is where it gets used mostly in the main stream. I've using AOP to apply caching services, transaction management, resource management, etc. to any number of objects in an application. I am currently working with a team of folks on the CDI implementation for the revived JSR-107 JCache. AOP is not a panacea, but it certainly fits a lot of otherwise difficult use cases. You can think of AOP as a dynamic decorator design pattern. The decorator pattern allows additional behavior to be added to an existing class by wrapping the original class and duplicating its interface and then delegating to the original. See this article decorator pattern for more detail about the decorator design pattern. (Notice in addition to supporting AOP style interception CDI also supports actual decorators, which are not covered in this article.) Sample application revisited For this introduction to AOP, let's take a simple example, let's apply security services to our Automated Teller Machine example from the first the first in this series. Let's say when a user logs into a system that a SecurityToken is created that carries the user's credentials and before methods on objects get invoked, we want to check to see if the user has credentials to invoke these methods. For review, let's look at the AutomatedTellerMachine interface. Code Listing: AutomatedTellerMachine interface package org.cdi.advocacy; import java.math.BigDecimal; public interface AutomatedTellerMachine { public abstract void deposit(BigDecimal bd); public abstract void withdraw(BigDecimal bd); } In a web application, you could write a ServletFilter, that stored this SecurityToken in HttpSession and then on every request retrieved the token from Session and put it into a ThreadLocal variable where it could be accessed from a SecurityService that you could implement. Perhaps the objects that needed the SecurityService could access it as follows: Code Listing: AutomatedTellerMachineImpl implementing security without AOP public void deposit(BigDecimal bd) { /* If the user is not logged in, don't let them use this method */ if(!securityManager.isLoggedIn()){ throw new SecurityViolationException(); } /* Only proceed if the current user is allowed. */ if (!securityManager.isAllowed("AutomatedTellerMachine", operationName)){ throw new SecurityViolationException(); } ... transport.communicateWithBank(...); } In our ATM example, the above might work out well, but imagine a system with thousands of classes that needed security. Now imagine, the way we check to see if a user is "logged in" changed. If we put this code into every method that needed security, then we could possibly have to change this a thousand times if we changed the way we checked to see if a user was logged in. What we want to do instead is to use CDI to create a decorated version of the AutomateTellerMachineImpl bean. The decorated version would add the additional behavior to the AutomateTellerMachineImpl object without changing the actual implementation of the AutomateTellerMachineImpl. In AOP speak, this concept is called a cross-cutting concern. A cross-cutting concern is a concern that crosses the boundry of many objects. CDI does this by creating what is called an AOP proxy. An AOP proxy is like a dynamic decorator. Underneath the covers CDI can generate a class at runtime (the AOP proxy) that has the same interface as our AutomatedTellerMachine. The AOP proxy wraps our existing atm object and provides additional behavior by delegating to a list of method interceptors. The method interceptors provide the additional behavior and are similar to ServletFilters but for methods instead of requests. Diagrams of CDI AOP support Thus before we added CDI AOP, our atm example was like Figure 1. Figure 1: Before AOP advice After we added AOP support, we now get an AOP proxy that applies the securityAdvice to the atm as show in figure 2. Figure 2: After AOP advice You can see that the AOP proxy implements the AutomatedTellerMachine interface. When the client object looks up the atm and starts invoking methods instead of executing the methods directly, it executes the method on the proxy, which then delegates the call to a series of method interceptor called advice, which eventually invoke the actual atm instance (now called atmTarget). Let's actually look at the code for this example. For this example, we will use a simplified SecurityToken that gets stored into a ThreadLocal variable, but one could imagine one that was populated with data from a database or an LDAP server or some other source of authentication and authorization. Here is the SecurityToken, which gets stored into a ThreadLocal variable, for this example: SecurityToken.java Gets stored in ThreadLocal package org.cdi.advocacy.security; /** * @author Richard Hightower * */ public class SecurityToken { private boolean allowed; private String userName; public SecurityToken() { } public SecurityToken(boolean allowed, String userName) { super(); this.allowed = allowed; this.userName = userName; } public boolean isAllowed(String object, String methodName) { return allowed; } /** * @return Returns the allowed. */ public boolean isAllowed() { return allowed; } /** * @param allowed The allowed to set. */ public void setAllowed(boolean allowed) { this.allowed = allowed; } /** * @return Returns the userName. */ public String getUserName() { return userName; } /** * @param userName The userName to set. */ public void setUserName(String userName) { this.userName = userName; } } The SecurityService stores the SecurityToken into the ThreadLocal variable, and then delegates to it to see if the current user has access to perform the current operation on the current object as follows: SecurityService.java Service package org.cdi.advocacy.security; public class SecurityService { private static ThreadLocal currentToken = new ThreadLocal(); public static void placeSecurityToken(SecurityToken token){ currentToken.set(token); } public static void clearSecuirtyToken(){ currentToken.set(null); } public boolean isLoggedIn(){ SecurityToken token = currentToken.get(); return token!=null; } public boolean isAllowed(String object, String method){ SecurityToken token = currentToken.get(); return token.isAllowed(); } public String getCurrentUserName(){ SecurityToken token = currentToken.get(); if (token!=null){ return token.getUserName(); }else { return "Unknown"; } } } The SecurityService will throw a SecurityViolationException if a user is not allowed to access a resource. SecurityViolationException is just a simple exception for this example. SecurityViolationException.java Exception package com.arcmind.springquickstart.security; /** * @author Richard Hightower * */ public class SecurityViolationException extends RuntimeException { /** * */ private static final long serialVersionUID = 1L; } To remove the security code out of the AutomatedTellerMachineImpl class and any other class that needs security, we will write an Aspect in CDI to intercept calls and perform security checks before the method call. To do this we will create a method interceptor (known is AOP speak as an advice) and intercept method calls on the atm object. Here is the SecurityAdvice class which will intercept calls on the AutomatedTellerMachineImpl class. SecurityAdvice package org.cdi.advocacy.security; import javax.inject.Inject; import javax.interceptor.AroundInvoke; import javax.interceptor.Interceptor; import javax.interceptor.InvocationContext; /** * @author Richard Hightower */ @Secure @Interceptor public class SecurityAdvice { @Inject private SecurityService securityManager; @AroundInvoke public Object checkSecurity(InvocationContext joinPoint) throws Exception { System.out.println("In SecurityAdvice"); /* If the user is not logged in, don't let them use this method */ if(!securityManager.isLoggedIn()){ throw new SecurityViolationException(); } /* Get the name of the method being invoked. */ String operationName = joinPoint.getMethod().getName(); /* Get the name of the object being invoked. */ String objectName = joinPoint.getTarget().getClass().getName(); /* * Invoke the method or next Interceptor in the list, * if the current user is allowed. */ if (!securityManager.isAllowed(objectName, operationName)){ throw new SecurityViolationException(); } return joinPoint.proceed(); } } Notice that we annotate the SecuirtyAdvice class with an @Secure annotation. The @Secure annotation is an @InterceptorBinding. We use it to denote both the interceptor and the classes it intercepts. More on this later. Notice that we use @Inject to inject the securityManager. Also we mark the method that implements that around advice with and @AroundInvoke annotation. This essentially says this is the method that does the dynamic decoration. Thus, the checkSecurity method of SecurityAdvice is the method that implements the advice. You can think of advice as the decoration that we want to apply to other objects. The objects getting the decoration are called advised objects. Notice that the SecurityService gets injected into the SecurityAdvice and the checkSecurity method uses the SecurityService* to see if the user is logged in and the user has the rights to execute the method. An instance of InvocationContext, namely joinPoint, is passed as an argument to checkSecurity. The InvocationContext has information about the method that is being called and provides control that determines if the method on the advised object's methods gets invoked (e.g., AutomatedTellerMachineImpl.withdraw and AutomatedTellerMachineImpl.deposit). If *`joinPoint.proceed()`* is not called then the wrapped method of the advised object (withdraw or deposit) is not called. (The proceed method causes the actual decorated method to be invoked or the next interceptor in the chain to get invoked.) In Spring, to apply an Advice like SecurityAdvice to an advised object, you need a pointcut. A pointcut is like a filter that picks the objects and methods that get decorated. In CDI, you just mark the class or methods of the class that you want decorated with an interceptor binding annotation. There is no complex pointcut language. You could implement one as a CDI extention, but it does not come with CDI by default. CDI uses the most common way developer apply interceptors, i.e., with annotations. CDI scans each class in each jar (and other classpath locations) that has a META-INF/beans.xml. The SecurityAdvice get installed in the CDI beans.xml. META-INF/beans.xml org.cdi.advocacy.security.SecurityAdvice You can install interceptors in the order you want them called. In order to associate a interceptor with the classes and methods it decorates, you have to define an InterceptorBinding annotation. An example of such a binding is defined below in the @Secure annotation. Secure.java annotation package org.cdi.advocacy.security; import java.lang.annotation.Retention; import java.lang.annotation.Target; import static java.lang.annotation.ElementType.*; import static java.lang.annotation.RetentionPolicy.*; import javax.interceptor.InterceptorBinding; @InterceptorBinding @Retention(RUNTIME) @Target({TYPE, METHOD}) public @interface Secure { } Notice that we annotated the @Secure annotation with the @InterceptorBinding annotation. InterceptorBindings follow a lot of the same rules as Qualifiers as discussed in the first two articles in this series. InterceptorBindings are like qaulifiers for injection in that they can have members which can further qualify the injection. You can also disable InterceptorBinding annotation members from qualifying an interception by using the @NonBinding just like you can in Qualifiers. To finish our example, we need to annotate our AutomatedTellerMachine with the same @Secure annotation; thus, associating the AutomatedTellerMachine with our SecurityAdvice. AutomatedTellerMachine class using @Secure package org.cdi.advocacy; ... import javax.inject.Inject; import org.cdi.advocacy.security.Secure; @Secure public class AutomatedTellerMachineImpl implements AutomatedTellerMachine { @Inject @Json private ATMTransport transport; public void deposit(BigDecimal bd) { System.out.println("deposit called"); transport.communicateWithBank(null); } public void withdraw(BigDecimal bd) { System.out.println("withdraw called"); transport.communicateWithBank(null); } } You have the option of use @Secure on the methods or at the class level. In this example, we annotated the class itself, which then applies the interceptor to every method. Let's complete our example by reviewing the AtmMain main method that looks up the atm out of CDI's beanContainer. Let's review AtmMain as follows: AtmMain.java package org.cdi.advocacy; import java.math.BigDecimal; import org.cdi.advocacy.security.SecurityToken; import org.cdiadvocate.beancontainer.BeanContainer; import org.cdiadvocate.beancontainer.BeanContainerManager; import org.cdi.advocacy.security.SecurityService; public class AtmMain { public static void simulateLogin() { SecurityService.placeSecurityToken(new SecurityToken(true, "Rick Hightower")); } public static void simulateNoAccess() { SecurityService.placeSecurityToken(new SecurityToken(false, "Tricky Lowtower")); } public static BeanContainer beanContainer = BeanContainerManager .getInstance(); static { beanContainer.start(); } public static void main(String[] args) throws Exception { simulateLogin(); //simulateNoAccess(); AutomatedTellerMachine atm = beanContainer .getBeanByType(AutomatedTellerMachine.class); atm.deposit(new BigDecimal("1.00")); } } Continue reading... Click on the navigation links below the author bio to read the other pages of this article. Be sure to check out part I of this series as well! Although not a fan of EJB 3, Rick is a big fan of the potential of CDI and thinks that EJB 3.1 has come a lot closer to the mark. CDI Implementations - Resin Candi - Seam Weld - Apache OpenWebBeans Before we added AOP support when we looked up the atm, we looked up the object directly as shown in figure 1, now that we applied AOP when we look up the object we get what is in figure 2. When we look up the atm in the application context, we get the AOP proxy that applies the decoration (advice, method interceptor) to the atm target by wrapping the target and delegating to it after it invokes the series of method interceptors. Victroy lap The last code listing works just like you think. If you use simulateLogin, atm.deposit does not throw a SecurityException. If you use simulateNoAccess, it does throw a SecurityException. Now let's weave in a few more "Aspects" to the mix to drive some points home and to show how interception works with multiple interceptors. I will go quicker this time. LoggingInterceptor package org.cdi.advocacy; import java.util.Arrays; import java.util.logging.Logger; import javax.interceptor.AroundInvoke; import javax.interceptor.Interceptor; import javax.interceptor.InvocationContext; @Logable @Interceptor public class LoggingInterceptor { @AroundInvoke public Object log(InvocationContext ctx) throws Exception { System.out.println("In LoggingInterceptor"); Logger logger = Logger.getLogger(ctx.getTarget().getClass().getName()); logger.info("before call to " + ctx.getMethod() + " with args " + Arrays.toString(ctx.getParameters())); Object returnMe = ctx.proceed(); logger.info("after call to " + ctx.getMethod() + " returned " + returnMe); return returnMe; } } Now we need to define the Logable interceptor binding annotation as follows: package org.cdi.advocacy; import java.lang.annotation.Retention; import java.lang.annotation.Target; import static java.lang.annotation.ElementType.*; import static java.lang.annotation.RetentionPolicy.*; import javax.interceptor.InterceptorBinding; @InterceptorBinding @Retention(RUNTIME) @Target({TYPE, METHOD}) public @interface Logable { } Now to use it we just mark the methods where we want this logging. AutomatedTellerMachineImpl.java using Logable package org.cdi.advocacy; ... @Secure public class AutomatedTellerMachineImpl implements AutomatedTellerMachine { ... @Logable public void deposit(BigDecimal bd) { System.out.println("deposit called"); transport.communicateWithBank(null); } public void withdraw(BigDecimal bd) { System.out.println("withdraw called"); transport.communicateWithBank(null); } } Notice that we use the @Secure at the class level which will applies the security interceptor to every mehtod in the AutomatedTellerMachineImpl. But, we use @Logable only on the deposit method which applies it, you guessed it, only on the deposit method. Now you have to add this interceptor to the beans.xml: META-INF/beans.xml org.cdi.advocacy.LoggingInterceptor org.cdi.advocacy.security.SecurityAdvice When we run this again, we get something like this in our console output: May 15, 2011 6:46:22 PM org.cdi.advocacy.LoggingInterceptor log INFO: before call to public void org.cdi.advocacy.AutomatedTellerMachineImpl.deposit(java.math.BigDecimal) with args [1.00] May 15, 2011 6:46:22 PM org.cdi.advocacy.LoggingInterceptor log INFO: after call to public void org.cdi.advocacy.AutomatedTellerMachineImpl.deposit(java.math.BigDecimal) returned null Notice that the order of interceptors in the beans.xml file determines the order of execution in the code. (I added a println to each interceptor just to show the ordering.) When we run this, we get the following output. Output: In LoggingInterceptor In SecurityAdvice If we switch the order in the beans.xml file, we will get a different order in the console output. META-INF/beans.xml org.cdi.advocacy.security.SecurityAdvice org.cdi.advocacy.LoggingInterceptor In SecurityAdvice In LoggingInterceptor This is important as many interceptors can be applied. You have one place to set the order. Conclusion AOP is neither a cure all or voodoo magic, but a powerful tool that needs to be in your bag of tricks. The Spring framework has brought AOP to the main stream masses and Spring 2.5/3.x has simplified using AOP. CDI brings AOP and DI into the standard's bodies where it can get further mainstreamed, refined and become part of future Java standards like JCache, Java EE 6 and Java EE 7. You can use Spring CDI to apply services (called cross-cutting concerns) to objects using AOP's interception model. AOP need not seem like a foreign concept as it is merely a more flexible version of the decorator design pattern. With AOP you can add additional behavior to an existing class without writing a lot of wrapper code. This can be a real time saver when you have a use case where you need to apply a cross cutting concern to a slew of classes. To reiterate... CDI is the Java standard for dependency injection and interception (AOP). It is evident from the popularity of DI and AOP that Java needs to address DI and AOP so that it can build other standards on top of it. DI and AOP are the foundation of many Java frameworks. I hope you share my excitement of CDI as a basis for other JSRs, Java frameworks and standards. CDI is a foundational aspect of Java EE 6. It is or will be shortly supported by Caucho's Resin, IBM's WebSphere, Oracle's Glassfish, Red Hat's JBoss and many more application servers. CDI is similar to core Spring and Guice frameworks. However CDI is a general purpose framework that can be used outside of JEE 6. CDI simplifies and sanitizes the API for DI and AOP. I find that working with CDI based AOP is easier and covers the most common use cases. CDI is a rethink on how to do dependency injection and AOP (interception really). It simplifies it. It reduces it. It gets rid of legacy, outdated ideas. CDI is to Spring and Guice what JPA is to Hibernate, and Toplink. CDI will co-exist with Spring and Guice. There are plugins to make them interoperate nicely (more on these shortly). This is just a brief taste. There is more to come. Resources CDI Source CDI advocacy group CDI advocacy blog CDI advocacy google code project Google group for CDI advocacy Manisfesto version 1 Weld reference documentation CDI JSR299 Resin fast and light CDI and Java EE 6 Web Profile implementation CDI & JSF Part 1 Intro by Andy Gibson CDI & JSF Part 2 Intro by Andy Gibson CDI & JSF Part 3 Intro by Andy Gibson About the Author This article was written with CDI advocacy in mind by Rick Hightower with some collaboration from others. Rick Hightower has worked as a CTO, Director of Development and a Developer for the last 20 years. He has been involved with J2EE since its inception. He worked at an EJB container company in 1999. He has been working with Java since 1996, and writing code professionally since 1990. Rick was an early Spring enthusiast. Rick enjoys bouncing back and forth between C, Python, Groovy and Java development. Although not a fan of EJB 3, Rick is a big fan of the potential of CDI and thinks that EJB 3.1 has come a lot closer to the mark. Rick Hightower is CTO of Mammatus and is an expert on Java and Cloud Computing. There are 18 code listings in this article
May 25, 2011
·
82,965 Views
·
10 Likes
Comments
Apr 15, 2015 · Manuel Weiss
Feb 17, 2015 · Javin Paul
Apr 29, 2011 · James Sugrue
Spring and CDI living in harmony shows how to use the @Spring qualifier to inject Spring beans into CDI (which uses a custom Spring integration extension for CDI)
It is possible to inject CDI beans into Spring and Spring beans into CDI. It is even possible to inject CDI beans into Spring beans that have Spring injections that have CDI injections. :)
A more detailed write up is coming soon. But the blog post and a github project is out there in the mean time if you are curious. This is a real project and it has working code.
Check out these as well:
CDI Meet Spring, github project
Initial prototype to get the Spring Bridge for CDI working
Mapping every CDI bean into Spring application context with one line of XML
The CDI extension piece would not have been possible without help from the core Caucho/Resin Engineering team. The CDI/Spring extension works with Weld, OpenWebBeans and Resin Candi.
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
When I think of successful OS projects, they usually have on thing in common: good docs.
Facelets was well documented and easy to learn. Hibernate had excellent documents (not everyone agrees with this). Spring has excellent documents. etc. etc.
Docs are a good sign of the overall quality of a project. That being said. I am horrible at writing docs (see crank).
Apr 07, 2011 · Mike Coming
Apr 07, 2011 · Mike Coming
Apr 07, 2011 · Mike Coming
Apr 06, 2011 · Tony Thomas
I changed all < to < and all < to >. I actually have a Python text processor that I wrote that converts from google WIKI markup into other markups so it was as easy as adding
line = line.replace("<", "<").replace(">",">").
To the part that does the code processing.
Apr 06, 2011 · Rick Hightower
I changed all < to < and all < to >. I actually have a Python text processor that I wrote that converts from google WIKI markup into other markups so it was as easy as adding
line = line.replace("<", "<").replace(">",">").
To the part that does the code processing.
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Apr 06, 2011 · Mike Coming
Good eye. It appears I have a slight error in my code listing. DOH! I will fix it and repost that last listing. I meant to pass the annotation to annotation literal and then to the select. It appears I misfired. :)
Pobody's Nerfect.
Apr 06, 2011 · Mike Coming
Good eye. It appears I have a slight error in my code listing. DOH! I will fix it and repost that last listing. I meant to pass the annotation to annotation literal and then to the select. It appears I misfired. :)
Pobody's Nerfect.
Apr 06, 2011 · Mike Coming
Good eye. It appears I have a slight error in my code listing. DOH! I will fix it and repost that last listing. I meant to pass the annotation to annotation literal and then to the select. It appears I misfired. :)
Pobody's Nerfect.
Apr 06, 2011 · Mike Coming
Good eye. It appears I have a slight error in my code listing. DOH! I will fix it and repost that last listing. I meant to pass the annotation to annotation literal and then to the select. It appears I misfired. :)
Pobody's Nerfect.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Mike Coming
The example would not work if you "new"ed AutomatedTellerMachineImpl instead of looking it up.
Apr 05, 2011 · Tony Thomas
It is a bit shorter than Part 1
Apr 05, 2011 · Rick Hightower
It is a bit shorter than Part 1
Apr 05, 2011 · Mike Coming
Apr 05, 2011 · Mike Coming
Apr 05, 2011 · Mike Coming
Apr 05, 2011 · Mike Coming
Apr 05, 2011 · Mike Coming
All of the examples were tested with Resin CANDI and WELD.
I reserve the right to be wrong, but I am pretty sure I am right.
Apr 05, 2011 · Mike Coming
All of the examples were tested with Resin CANDI and WELD.
I reserve the right to be wrong, but I am pretty sure I am right.
Apr 05, 2011 · Mike Coming
All of the examples were tested with Resin CANDI and WELD.
I reserve the right to be wrong, but I am pretty sure I am right.
Mar 30, 2011 · Oni Musha
Mar 29, 2011 · Tony Thomas
Mar 29, 2011 · Tony Thomas
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Tony Thomas
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Tony Thomas
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Tony Thomas
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Tony Thomas
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Tony Thomas
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Tony Thomas
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Rick Hightower
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Rick Hightower
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Rick Hightower
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Rick Hightower
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Rick Hightower
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Rick Hightower
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Rick Hightower
As mentioned earlier, the Seam Weld project has a CDI plugin that provides a "config.xml" that is similar to Springs. Since it is a CDI plugin (called extensions), it should work on any standard CDI implementation. Expect a future article on using this plugin. Also Resin CANDI (another CDI implementation) has XML support, and this CDI XML support is also how you configure the server itself so the whole thing uses CDI throughout.
Since the Seam CDI Weld project has a nice plugin, it might become the de facto standard for when you want XML instead of annotations. Personally, I prefer to use the annotations whenever possible and keep the XML as small as possible.
Mar 29, 2011 · Jens Eckels
Mar 29, 2011 · Jens Eckels
Mar 29, 2011 · Jens Eckels
Mar 29, 2011 · Tony Thomas
One more thing. There are several unit testing frameworks for CDI. We plan on writing tutorials about them in the future. There is a lot more to come. There is a lot out there. CDI is nascent but coming together quickly.
Mar 29, 2011 · Rick Hightower
One more thing. There are several unit testing frameworks for CDI. We plan on writing tutorials about them in the future. There is a lot more to come. There is a lot out there. CDI is nascent but coming together quickly.
Mar 29, 2011 · Tony Thomas
Also you can use alternatives. There is a section in this tutorial on alternatives. Using @Alternative to select an Alternative Earlier, you may recall, we defined several alternative transports, namely, JsonRestAtmTransport and SoapRestAtmTransport. Imagine that you are an installer of ATM machines and you need to configure certain transports at certain locations. Our previous injection points essentially inject the default which is the StandardRestAtmTransport transport.
You can scan for it.
Here is a link to the section in the wiki version of this tutorial Alternatives
As cloves was saying if you wanted to use the XML files. Seam has XML CDI plugin that is similar to what you would expect in a spring context xml file. Resin also supports an XML file version. In most cases, you should be able to use Alternatives.
Mar 29, 2011 · Rick Hightower
Also you can use alternatives. There is a section in this tutorial on alternatives. Using @Alternative to select an Alternative Earlier, you may recall, we defined several alternative transports, namely, JsonRestAtmTransport and SoapRestAtmTransport. Imagine that you are an installer of ATM machines and you need to configure certain transports at certain locations. Our previous injection points essentially inject the default which is the StandardRestAtmTransport transport.
You can scan for it.
Here is a link to the section in the wiki version of this tutorial Alternatives
As cloves was saying if you wanted to use the XML files. Seam has XML CDI plugin that is similar to what you would expect in a spring context xml file. Resin also supports an XML file version. In most cases, you should be able to use Alternatives.
Mar 28, 2011 · Tony Thomas
The short answer is Alternatives. I don't remember if I cover them here or in the next article. (I wrote the example code already).
The longer answer will have to wait until I put the kids to bed.
Mar 28, 2011 · Rick Hightower
The short answer is Alternatives. I don't remember if I cover them here or in the next article. (I wrote the example code already).
The longer answer will have to wait until I put the kids to bed.
Mar 28, 2011 · Tony Thomas
Mar 28, 2011 · Rick Hightower
Jan 13, 2011 · Kirill Grouchnikov
Nov 17, 2009 · Lebon Bon Lebon
Nov 16, 2009 · Lebon Bon Lebon
Nov 16, 2009 · Lebon Bon Lebon
Feb 26, 2009 · Lowell Heddings
Seems Ken's excellent article on FP is in this NFJS magazine (http://www.nofluffjuststuff.com/magazine_subscribe.jsp).
Feb 26, 2009 · Peter Szinek
Still pushing Scala eh?
Ohhh.... I can see the mass adoption... Did I spell it wrong? Just because you and your nerdy friends (Bob Lee et al) like it and wrote some books on it does not mean the rest of the world will adopt it. Ok Bob was right about that whole AOP thing but what are the chances of him being right twice. Besides, I am partial to Clojure (http://clojure.org/).
You know for AOP to really get mass adoption it needed someone like Rod Johnson to come around and push it. I wonder who will back Groovy. If only some company, like Interface21 came around and backed Groovy development and promoted it. Oh wait.... Oh yeah... Oh cool.....
Just admit that I was right about Scala and you were wrong and get on with your life. :o) I give you permission not to mention Scala in next year's predictions when it does not grow in job demand again. Just forget you ever predicted it to grow.
BTW Did you see that Java job growth grew more in the last year than the entire Ruby market times two? Kind of makes you wonder just how dead is Java? It's alive!
I wish there was a langauge that had all of the cool dynamic Ruby language features but was designed from the ground up to take advantage of the JVM that all of the corporations in the world seem to use. I also wish the language would extend the Java API instead of coming up with an orthogonal API. It would be nice if this language was designed to have a low learning curve and to be very compatible with the Java language in terms of learning and interoperability. If only something like that existed... Oh wait... Oh yeah... Oh cool....
In all seriousness, there is one language (that runs in the JVM) that will see mass adoption in 2009, and it is Groovy. There that is my prediction.
Hint predictions are a lot easier if you wait for a trend to start happening and then you say its your prediction. If you are ever going to work at Gartner... you have to know this. I believe it is how they pay the bills when they are not getting paid for a prediction from a bunch of software vendors. I jest. I love you Gartner guys: don't sue me.
FYI: You might not be able to tell from this comment but I am big fan of Bob Lee and Ted Neward. I just don't always agree. Also, I found out that Bob is not such a big fan of Scala. He is a proponent of FP in general.
Feb 26, 2009 · David Salter
RE: "But generally, an academic paper written for academics before blogs existed shouldn't be scored the same as an unacademic blog post written for programmers with no attention span or experience of non-C-syntax languages."
I think the point is let's get it out of just the realm of academcis and describe FP in terms of ROI and feel free to dumb it down to problems that practioneers actually work-on on a daily basis. I think FP authors in general are starting to do this. There is a lot of work to be done.
The attitude that Ricky is conveying, to me, is exactly why FP has not (yet) made it to the mainstream. Let's insult the main stream developers. Fine, but who is going to let you play with your toys in their playground. C-syntax owns the world.
Rod Johnson et al brought AOP mainstream by demonstrating the benefit and building the tools and libraries with it that developer could use on their projects. They took AOP out of the realm of academics and into the Enterprise. Who is going to do this for FP?
To me, Jeff S is spot on. Well said Jeff S.
Now I digress.....
I just wrote an article on closures for groovy.dzone.com and Ken Sipe reviewed and shared an article he wrote on Functional Programming, which I then borrowed some ideas from which I covered in the last section (with some quotes and code snippets from Ken).
Ken Sipe's article is an excellent article on FP that introduces FP concepts. (Not public yet so.... you will have to wait)
Personally I think FP style programming will slowly become more mainstream as language features are slowly added to mainstream languages. In a way, it has already started happening.
That said, I look forward to the new book from the pragmatic series on Clojure from Stuart Halloway.
And reports of FP mass adoption are mostly fantasy.
See comments under Ted Neward predictions for more on this.
Jan 23, 2009 · Andrew Glover
Jan 22, 2009 · Andrew Glover
Matthias,
I have a lot of respect for you and for Oracle.
My boss at Intel once told me the great thing about standards is this: "There is a lot of them to choose from".
You could say the same about Ajax enabled JSF component suites. RichFaces, ADF, Tomahawk, ICEfaces, and about a 1/2 dozen more. How do you pick?
A while back I started using RichFaces. I evaluated Oracle ADF several years ago and it just did not work out for us, and at the time we decided to use RichFaces + Tomahawk instead.....We have been using RichFaces ever since, and with the publication of a recent RichFaces book; we finally learned how to use it well.
So questions come to my mind... How does Oracle ADF compare to RichFaces, ICEfaces, Tobago, Trinidad (where does Trinidad start and Oracle ADF continue)?
Also there is a pretty steep learning curve to learning some of these frameworks and getting around their many quirks. Which makes it difficult to switch as the investment in learning is high... How do you convince someone like myself to give Oracle ADF a try (or another try) who might be using one of the 8 other flavors of JSF Ajax enabled components?
Also how do the Ajax features in Oracle ADF align with the upcoming Ajax features included in JSF 2.0?
Always good to hear from you and this is a good tutorial.
To learn more about some of the other frameworks try this site:
http://www.jsfmatrix.net/
Jan 15, 2009 · Peter Stofferis
Jan 15, 2009 · Lebon Bon Lebon
Jan 12, 2009 · Mr B Loid
Ales,
Thanks for this article. I am glad to see that the JBoss microcontainer is progressing. In the market place of ideas, it is good to have more than one DI/IoC containers.
It seems Spring picked up a lot of good ideas from Guice and WebBeans. I am very curious about the configuration of classloaders as it relates to JBoss microcontainer.
Although I will very likely continue to use Spring IoC, I will also continue to see what the JBoss team is cooking up. After all Spring is a technology not a religion.
Thanks again and I look forward to your future articles.
BTW Any plans for an article comparing JBoss microcontainer to Spring?
Thanks again,
Your truly,
Rick Hightower
Dec 26, 2008 · Mr B Loid
Dec 22, 2008 · Mr B Loid
2 Articles on JSF in the top 5
2 Articles on JPA/Hibernate (Java ORM)
1 Article on Spring
It is good to see that JSF interest is still alive and kicking despite the DOA JSF theorists.
Not a single article on Wicket, Tapestry, Groovy, Grails, Java FX, Spring MVC, JRuby, in the top ten despite the large fan clubs behind these technologies. (BTW I like a few of the above listed as well.)
Enthusiam does not equate to interests by the silent majority.
Dec 22, 2008 · Mr B Loid
It is good to be in the top ten. Thanks.
It seems many of this articles are from before May. It seems you based the top ten list on the top ten with the most hits. I wonder if the list would change if you adjusted for the age of the article.
Articles written in November/December would do much better if you adjusted for age against articles in April. Just a thought....
Of course after you recalculated, I may fall off the list.
Nov 30, 2008 · Jens Eckels
Nov 30, 2008 · Jens Eckels
Nov 30, 2008 · Jens Eckels
Nov 14, 2008 · Jens Eckels
Nov 14, 2008 · Jens Eckels
Nov 14, 2008 · Jens Eckels
Nov 13, 2008 · Jens Eckels
Thanks Ravi. I really appreciate the positive feedback. It really helps. Thanks.
Nov 13, 2008 · Jens Eckels
Thanks Ravi. I really appreciate the positive feedback. It really helps. Thanks.
Nov 13, 2008 · Jens Eckels
Nov 13, 2008 · Jens Eckels
Nov 11, 2008 · Jens Eckels
Nov 11, 2008 · Jens Eckels
Nov 11, 2008 · Jens Eckels
Mar 24, 2008 · Lebon Bon Lebon
I am no Flex expert, but isn't Flex Open Source now...??
http://www.flex.org
http://labs.adobe.com/wiki/index.php/Flex:Open_Source
Mar 24, 2008 · Lebon Bon Lebon
I am no Flex expert, but isn't Flex Open Source now...??
http://www.flex.org
http://labs.adobe.com/wiki/index.php/Flex:Open_Source
Mar 24, 2008 · Lebon Bon Lebon
I am no Flex expert, but isn't Flex Open Source now...??
http://www.flex.org
http://labs.adobe.com/wiki/index.php/Flex:Open_Source
Mar 24, 2008 · Lebon Bon Lebon
I am no Flex expert, but isn't Flex Open Source now...??
http://www.flex.org
http://labs.adobe.com/wiki/index.php/Flex:Open_Source
Mar 24, 2008 · Lebon Bon Lebon
I am quite sure MS only has good intentions. :o)
SWT vs. Swing.... Why would they want to get involved in that?
Mar 21, 2008 · Lebon Bon Lebon
Vista motivated me to swtich to Mac OS X. My primary development box is now a MacBook Pro as of about three weeks ago after struggling with Vista on my Sony VAIO for about six months.
My MacBook pro is the best laptop I have ever owned. I took my Sony laptop and installed Ubuntu on it (My Sony laptop is a lot faster now and now the Hibernate laptop feature actually works). I am a very happy Mac user.
Mar 10, 2008 · Nick Tong
Mar 10, 2008 · Nick Tong
Mar 10, 2008 · Nick Tong
Mar 02, 2008 · Mikhail Koryak
I personally tend to use Spring but I have already had clients who use EJB 3. I'd appreciate a light version for when I have to use it. In addition, EJB has some nice integration with WebBeans and Seam.
Here are some recent related links:
Mar 02, 2008 · Roman Pichlik
I personally tend to use Spring but I have already had clients who use EJB 3. I'd appreciate a light version for when I have to use it. In addition, EJB has some nice integration with WebBeans and Seam.
Here are some recent related links:
Feb 23, 2008 · Lebon Bon Lebon
It is great to get this information about EclipseLink and TopLink. What happened four years ago with TopLink should be less of an issue going forward.
You thought I was biased after I wrote.... "I'd love to see some viable alternatives to Hibernate", Wow! Okay I am a bit biased towards Hibernate but is mostly a comfort zone issue which is mostly due to being mostly familiar with JPA and Hibernate. Who isn't a bit biased? :o)
I have been using Hibernate for over 4 years and I still learn new tricks, and caveats so switching means a whole new learning curve. If I was going to switch, their would have to be a good case why I should switch because even if I decided to switch, I would have to convince others. It just seems the ORM guys are ignoring the elephant in the room.
The JPA interfaces to Hibernate makes more sense than the original interface. I only use the original interface when I need to use a featue that does not exists in the JPA interface. I find standards a good thing especially when it means improving on what is already there. Also, Hibernate usage has gone up after JPA was adopted so if anything, it made Hibernate not just the de facto standard but the leading implementer of the standard. At the same time, it did level the playing field so I hope to see some viable alternatives. Competition is good for technology.
The TopLink/EclipseLink guys are well represented. The JPOX guys are also well represented. The ones I was truly reaching out to (OpenJPA).... are only slightly represented... even after taunting and begging. I wrote one email to their mailing list wrt to this post. I wrote one email to Patrick as well. I guess they are just too busy.
I'd love to get 5 reason from each ORM why they think people should switch to their ORM from Hibernate, but alas... it is unlikely to happen.
Heck even the "JDBC rocks crowd" and the iBatis guys are well represented and they were not even invited to the party (although we enjoy their comments).
Oh yeah... one more thing... we did not get so much as a peep from the Cayenne guys either...
rick hightowercto of arcMindbloglinkedinFeb 23, 2008 · Lebon Bon Lebon
It is great to get this information about EclipseLink and TopLink. What happened four years ago with TopLink should be less of an issue going forward.
You thought I was biased after I wrote.... "I'd love to see some viable alternatives to Hibernate", Wow! Okay I am a bit biased towards Hibernate but is mostly a comfort zone issue which is mostly due to being mostly familiar with JPA and Hibernate. Who isn't a bit biased? :o)
I have been using Hibernate for over 4 years and I still learn new tricks, and caveats so switching means a whole new learning curve. If I was going to switch, their would have to be a good case why I should switch because even if I decided to switch, I would have to convince others. It just seems the ORM guys are ignoring the elephant in the room.
The JPA interfaces to Hibernate makes more sense than the original interface. I only use the original interface when I need to use a featue that does not exists in the JPA interface. I find standards a good thing especially when it means improving on what is already there. Also, Hibernate usage has gone up after JPA was adopted so if anything, it made Hibernate not just the de facto standard but the leading implementer of the standard. At the same time, it did level the playing field so I hope to see some viable alternatives. Competition is good for technology.
The TopLink/EclipseLink guys are well represented. The JPOX guys are also well represented. The ones I was truly reaching out to (OpenJPA).... are only slightly represented... even after taunting and begging. I wrote one email to their mailing list wrt to this post. I wrote one email to Patrick as well. I guess they are just too busy.
I'd love to get 5 reason from each ORM why they think people should switch to their ORM from Hibernate, but alas... it is unlikely to happen.
Heck even the "JDBC rocks crowd" and the iBatis guys are well represented and they were not even invited to the party (although we enjoy their comments).
Oh yeah... one more thing... we did not get so much as a peep from the Cayenne guys either...
rick hightowercto of arcMindbloglinkedinFeb 23, 2008 · Lebon Bon Lebon
It is great to get this information about EclipseLink and TopLink. What happened four years ago with TopLink should be less of an issue going forward.
You thought I was biased after I wrote.... "I'd love to see some viable alternatives to Hibernate", Wow! Okay I am a bit biased towards Hibernate but is mostly a comfort zone issue which is mostly due to being mostly familiar with JPA and Hibernate. Who isn't a bit biased? :o)
I have been using Hibernate for over 4 years and I still learn new tricks, and caveats so switching means a whole new learning curve. If I was going to switch, their would have to be a good case why I should switch because even if I decided to switch, I would have to convince others. It just seems the ORM guys are ignoring the elephant in the room.
The JPA interfaces to Hibernate makes more sense than the original interface. I only use the original interface when I need to use a featue that does not exists in the JPA interface. I find standards a good thing especially when it means improving on what is already there. Also, Hibernate usage has gone up after JPA was adopted so if anything, it made Hibernate not just the de facto standard but the leading implementer of the standard. At the same time, it did level the playing field so I hope to see some viable alternatives. Competition is good for technology.
The TopLink/EclipseLink guys are well represented. The JPOX guys are also well represented. The ones I was truly reaching out to (OpenJPA).... are only slightly represented... even after taunting and begging. I wrote one email to their mailing list wrt to this post. I wrote one email to Patrick as well. I guess they are just too busy.
I'd love to get 5 reason from each ORM why they think people should switch to their ORM from Hibernate, but alas... it is unlikely to happen.
Heck even the "JDBC rocks crowd" and the iBatis guys are well represented and they were not even invited to the party (although we enjoy their comments).
Oh yeah... one more thing... we did not get so much as a peep from the Cayenne guys either...
rick hightowercto of arcMindbloglinkedinFeb 23, 2008 · Lebon Bon Lebon
It is good to get some perspective on this stuff. I haven't worked with JDO (most folks I run into have not either...).
If JDO == beta-max and JPA == VHS... it is good to know that eventually it won't matter b/c we will all be using Blueray in 20 years.... whatever that is. Ha!
rick hightowercto of arcMindbloglinkedinFeb 23, 2008 · Tabrez Iqbal
Feb 23, 2008 · Tabrez Iqbal
Feb 23, 2008 · Tabrez Iqbal
Feb 23, 2008 · Tabrez Iqbal
Feb 23, 2008 · Tabrez Iqbal
As always Jim... it is good to hear from a good friend. Thanks for the info on Seam. Seams seems to have quite a lot of features. There is a lot to learn. How easy is it to work with Seam and Spring? In your opinion....
Seam adoption is a bit weaker than I would imagine. Do you suppose it is becuase... early on Seam hitched their wagon to EJB3 and was sort of billed as the anit-Spring? It seems at first it did not have much support for Spring.
Seam is a little long in the tooth not to get more job demand. In fact, you can almost attribute its real growth to when is added support for Spring. (Just an opinion...) So now that it has support for Spring.... I guess there is nothing holding me back...
I am glad it has solid integration with Spring. I know we are running into some use cases where Seam, Orchestra or possibly SWF could help out. My brain is already full with JSF, JPA and Spring... one more framework and it will implode.... just another thin mint.
Feb 23, 2008 · Tabrez Iqbal
As always Jim... it is good to hear from a good friend. Thanks for the info on Seam. Seams seems to have quite a lot of features. There is a lot to learn. How easy is it to work with Seam and Spring? In your opinion....
Seam adoption is a bit weaker than I would imagine. Do you suppose it is becuase... early on Seam hitched their wagon to EJB3 and was sort of billed as the anit-Spring? It seems at first it did not have much support for Spring.
Seam is a little long in the tooth not to get more job demand. In fact, you can almost attribute its real growth to when is added support for Spring. (Just an opinion...) So now that it has support for Spring.... I guess there is nothing holding me back...
I am glad it has solid integration with Spring. I know we are running into some use cases where Seam, Orchestra or possibly SWF could help out. My brain is already full with JSF, JPA and Spring... one more framework and it will implode.... just another thin mint.
Feb 23, 2008 · Tabrez Iqbal
As always Jim... it is good to hear from a good friend. Thanks for the info on Seam. Seams seems to have quite a lot of features. There is a lot to learn. How easy is it to work with Seam and Spring? In your opinion....
Seam adoption is a bit weaker than I would imagine. Do you suppose it is becuase... early on Seam hitched their wagon to EJB3 and was sort of billed as the anit-Spring? It seems at first it did not have much support for Spring.
Seam is a little long in the tooth not to get more job demand. In fact, you can almost attribute its real growth to when is added support for Spring. (Just an opinion...) So now that it has support for Spring.... I guess there is nothing holding me back...
I am glad it has solid integration with Spring. I know we are running into some use cases where Seam, Orchestra or possibly SWF could help out. My brain is already full with JSF, JPA and Spring... one more framework and it will implode.... just another thin mint.
Feb 21, 2008 · Lebon Bon Lebon
Feb 21, 2008 · Lebon Bon Lebon
Feb 21, 2008 · Lebon Bon Lebon
Feb 21, 2008 · Lebon Bon Lebon
Feb 21, 2008 · Lebon Bon Lebon
Hi Rick,
I noticed in my emailbox that some more comments are being posted than displayed here. Some seem valuable comments so I don't know why they don't appear? Anyway, your question on whether a comparison can be found between JPA and JDO can be found here (I believe Andy already mentioned it):
http://www.jpox.org/docs/persistence_technology.html
Some older blog entries which also give some nice insight:http://www.jroller.com/matthewadams/entry/quick_comparison_of_ejb_3http://www.jroller.com/ThoughtPark/entry/ejb3_persistence_an_inferior_standardIf you want to have a quick overview of all the possibilities of JDO2 (like you asked), this quick reference is still very helpful I think:http://www.solarmetric.com/resources/jdo-api-quickref.pdfBtw, the JDO expert group is very active (JDO 2.1 maintenance release is about to launched) and they are very willing to listen to input from the community.kind regards,Christiaan[/quote]
Looks like I have quite a reading assignment. I will try to get to these tonight. I did browse them. Thanks for taking the time to compile the list.
So if I can just put words into your mouth... In your opinion ORMs that support JDO and JPA are a better pick than those that do not. Seems demand for JPA has matched JDO already....
How can JDO providers be more effective at making their case? Is JDO the beta-max of ORMs and Hibernate/JPA the VHS? Will JDO go the way of Beta-max? Should we all just wait for blueray.... :o)
rick hightowercto of arcMindbloglinkedinFeb 21, 2008 · Lebon Bon Lebon
Hi Rick,
I noticed in my emailbox that some more comments are being posted than displayed here. Some seem valuable comments so I don't know why they don't appear? Anyway, your question on whether a comparison can be found between JPA and JDO can be found here (I believe Andy already mentioned it):
http://www.jpox.org/docs/persistence_technology.html
Some older blog entries which also give some nice insight:http://www.jroller.com/matthewadams/entry/quick_comparison_of_ejb_3http://www.jroller.com/ThoughtPark/entry/ejb3_persistence_an_inferior_standardIf you want to have a quick overview of all the possibilities of JDO2 (like you asked), this quick reference is still very helpful I think:http://www.solarmetric.com/resources/jdo-api-quickref.pdfBtw, the JDO expert group is very active (JDO 2.1 maintenance release is about to launched) and they are very willing to listen to input from the community.kind regards,Christiaan[/quote]
Looks like I have quite a reading assignment. I will try to get to these tonight. I did browse them. Thanks for taking the time to compile the list.
So if I can just put words into your mouth... In your opinion ORMs that support JDO and JPA are a better pick than those that do not. Seems demand for JPA has matched JDO already....
How can JDO providers be more effective at making their case? Is JDO the beta-max of ORMs and Hibernate/JPA the VHS? Will JDO go the way of Beta-max? Should we all just wait for blueray.... :o)
rick hightowercto of arcMindbloglinkedinFeb 21, 2008 · Lebon Bon Lebon
Hi Rick,
I noticed in my emailbox that some more comments are being posted than displayed here. Some seem valuable comments so I don't know why they don't appear? Anyway, your question on whether a comparison can be found between JPA and JDO can be found here (I believe Andy already mentioned it):
http://www.jpox.org/docs/persistence_technology.html
Some older blog entries which also give some nice insight:http://www.jroller.com/matthewadams/entry/quick_comparison_of_ejb_3http://www.jroller.com/ThoughtPark/entry/ejb3_persistence_an_inferior_standardIf you want to have a quick overview of all the possibilities of JDO2 (like you asked), this quick reference is still very helpful I think:http://www.solarmetric.com/resources/jdo-api-quickref.pdfBtw, the JDO expert group is very active (JDO 2.1 maintenance release is about to launched) and they are very willing to listen to input from the community.kind regards,Christiaan[/quote]
Looks like I have quite a reading assignment. I will try to get to these tonight. I did browse them. Thanks for taking the time to compile the list.
So if I can just put words into your mouth... In your opinion ORMs that support JDO and JPA are a better pick than those that do not. Seems demand for JPA has matched JDO already....
How can JDO providers be more effective at making their case? Is JDO the beta-max of ORMs and Hibernate/JPA the VHS? Will JDO go the way of Beta-max? Should we all just wait for blueray.... :o)
rick hightowercto of arcMindbloglinkedinFeb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Lebon Bon Lebon
Actually this is very wrong. I have seen plenty and I mean plenty of apps that have gone into production with Hibernate and performed quite well. Your assertion is wrong. Very wrong. You can replace what Hibernate does with SQL if you need to (rare). There are plenty of techniques to efficiently load data.
Feb 21, 2008 · Tabrez Iqbal
Feb 21, 2008 · Tabrez Iqbal
Feb 21, 2008 · Tabrez Iqbal
Feb 21, 2008 · Tabrez Iqbal
Feb 21, 2008 · Lebon Bon Lebon
Christaan,
Thanks for writing. I have never used JDO in anger. I have used several homegrown ORMs of varying degrees of quality (one even written by me), EJB CMP/CMR 2.x, Hibernate, and several flavors of JPA.
Why do you think JPA has done much better in the market place than JDO?
BTW I am not disagreeing with you and perhaps I will try a JDO flavor of ORM.
"The JDO spec really enables transparent persistency in my opinion." Can you show a short code example or link to one that compares JPA to JDO clearly showing JDO more transparent?
Feb 21, 2008 · Lebon Bon Lebon
Christaan,
Thanks for writing. I have never used JDO in anger. I have used several homegrown ORMs of varying degrees of quality (one even written by me), EJB CMP/CMR 2.x, Hibernate, and several flavors of JPA.
Why do you think JPA has done much better in the market place than JDO?
BTW I am not disagreeing with you and perhaps I will try a JDO flavor of ORM.
"The JDO spec really enables transparent persistency in my opinion." Can you show a short code example or link to one that compares JPA to JDO clearly showing JDO more transparent?
Feb 21, 2008 · Lebon Bon Lebon
[quote=pinchworm]
Your question is meaningless without defining what you mean by "best".
[/quote]
I define best as "most advantageous, suitable, or desirable: the best way" similar to the dictionay definition really.
[quote=pinchworm]
There is no best tool for every solution. Sometimes Java is the right way to solve a problem. Sometimes Ruby is. Sometimes pen and paper is.
[/quote]
I can never get paper to compile. I also find that the performance speed of paper seriously lacking not to mention the frequent paper cuts. I don't find Ruby best for anything... I would much rather use Java, Groovy, Python or perhaps sharp ginsu knives! To each his own!
[quote=pinchworm]
I would be very interested in hearing about those situations where Hibernate is not the best choice, since it is already clearly the best choice in many areas (support, documentation, community).
[/quote]
I agree and a big me too. Which is why I wrote this post!
rick hightowercto of arcMindbloglinkedinFeb 21, 2008 · Lebon Bon Lebon
[quote=pinchworm]
Your question is meaningless without defining what you mean by "best".
[/quote]
I define best as "most advantageous, suitable, or desirable: the best way" similar to the dictionay definition really.
[quote=pinchworm]
There is no best tool for every solution. Sometimes Java is the right way to solve a problem. Sometimes Ruby is. Sometimes pen and paper is.
[/quote]
I can never get paper to compile. I also find that the performance speed of paper seriously lacking not to mention the frequent paper cuts. I don't find Ruby best for anything... I would much rather use Java, Groovy, Python or perhaps sharp ginsu knives! To each his own!
[quote=pinchworm]
I would be very interested in hearing about those situations where Hibernate is not the best choice, since it is already clearly the best choice in many areas (support, documentation, community).
[/quote]
I agree and a big me too. Which is why I wrote this post!
rick hightowercto of arcMindbloglinkedinFeb 21, 2008 · Lebon Bon Lebon
[quote=pinchworm]
Your question is meaningless without defining what you mean by "best".
[/quote]
I define best as "most advantageous, suitable, or desirable: the best way" similar to the dictionay definition really.
[quote=pinchworm]
There is no best tool for every solution. Sometimes Java is the right way to solve a problem. Sometimes Ruby is. Sometimes pen and paper is.
[/quote]
I can never get paper to compile. I also find that the performance speed of paper seriously lacking not to mention the frequent paper cuts. I don't find Ruby best for anything... I would much rather use Java, Groovy, Python or perhaps sharp ginsu knives! To each his own!
[quote=pinchworm]
I would be very interested in hearing about those situations where Hibernate is not the best choice, since it is already clearly the best choice in many areas (support, documentation, community).
[/quote]
I agree and a big me too. Which is why I wrote this post!
rick hightowercto of arcMindbloglinkedinFeb 21, 2008 · Lebon Bon Lebon
Can I get 5 technical reasons to use OpenJPA instead of Hibernate? No. Ok, can you give me 4 reasons to use OpenJPA instead of Hibernate. ... ... Can I get 1 technical reason to use OpenJPA over Hibernate? How about a non-techncial reason? How about a positive experience? No... nothing... thank you.... good night.... frustration!
The best response was from the JPOX guys, and I did not even mention them in the original post. They seem to get it. I have never used JPOX but I admire their ability to state their case. I hope to hear good things about JPOX in the future.
Someone posted a interview with Gavin King which got deleted (not by me but by another moderator--I assume). WOW! Gavin is pretty passionate and technically savvy. He has natural marketing skills! BTW I did not delete it and am not sure who posted the interview (I read it on my blackberry and it was gone before I got here with my laptop). OpenJPA, JPOX, etc. could use someone with that technical marketing capabilities like Gavin. Without that I don't see any of them making inroad into the ever increasing Hibernate mindshare (assuming their technology is worthy of course).
After reading this thread and reading Jonathan's comment thread, it seems Hibernate does really well. Gavin's responses to Jonathan are very well done if you get a chance, check out the thread. Perhaps this is a case where the herd is right. I just have not seen any compelling arguments to switch to OpenJPA, etc.
TopLink took a bit of a bashing in this thread not by me. Seems no one came out to defend TopLink either.
This response perplexed me.....
What do you mean by this? I thought TopLink Essentials was the reference implementation for JPA not OpenJPA. Can you explain this? I use JPA and Hibernate... I am not on any JDO or JPA spec comittee so not an expert on what is and is not part of the spec.
This posts was all about ORMs and a bunch of holigan, iBatis folks break into the party. :o) (see big smiley that says just kidding).
I have actually used iBatis and I do actually like it. I prefer Hibernate for greenfield apps. I also find that Hibernate is pretty flexible with legacy mappings despite the claims to the contrary. There have been times when I have heard that it is not possible to map Hibernate to this XYZ table structure, view, yada, yada... and I was able to do it farily quickly with Hibernate. Get the book. Read the book. You can do wonders with Hibernate.
However, iBatis sure makes it easy to map to a legacy database, even if the db is a bit whack. It is a good tool to have in the bag of tricks.
For the "just use JDBC crowd", I created a custom course once that implemented a DAO using just JDBC (it actually used Spring's JDBC support which simplifies working with JDBC), then as part of the course the developers rewrote the DAO object using Hibernate (this was before JPA and before so many open source choices for JPA and JDO).
The Hibernate version was a fraction of the Spring JDBC one (it was like a 1/4 or a 1/6 the size perhaps less). It was a lot less code. After this there were few Hibernate detractors. Keep in mind, the JDBC version would have been a lot more without the Spring JDBC support. Hand writing JDBC for CRUD operations is a waste of time in most cases.
Had we been comparing straight JDBC (no Spring helper classes), it would have been a lot larger. Who has got time to hand write all of this?
Sure there are some blind alleys when learning JPA and there is a learning curve, but it seems worth it to me. I work with JPA a lot and really like it. Even on a recent large project, we mostly used JPA and there was only one use case where we used JDBC/SQL instead of JPA.
rick hightowercto of arcMindbloglinkedinFeb 21, 2008 · Marc Chung
I had the "misfortune" of working with Java 5 and then going back to JDK 1.4 for 18 months to work with a great client.
All I can say was that it was painful going back to JDK 1.4.
Generics may not be perfect but I prefer type safe lists to random collection of gak. I much prefer List<Employee> getEmployees() to List getEmployees() especially when you find the that the method does not return exactly what you thought it did (employees example probably not the best).
I find all developers that I work with prefer Java 5+ and would not look forward to going back to JDK 1.4. In fact, I have never met a Java developer in person who prefers JDK 1.4 to Java 5.
I am for the evolution of Java. I don't want to go back to 1990s Java programming. Bring on closures, inferred typing, etc. "I say let... lets evolve, let the chips fall where they may."--FC 1999
Okay I read his post and... he makes some really good points about annotations. I don't agree with him about Generics per se (I thought it was a needed tradeoff for backwards compatibility), but I have never been happy with annotations. To each his own.
rick hightowercto of arcMindbloglinkedinFeb 20, 2008 · Lebon Bon Lebon
Well maybe you should spend some time on it. It seems like Hibernate is the de facto choice for many. I remember when Hibernate came out they were pretty direct with their thoughts about EJB CMP/CMR. It is hard to recommend something like JPOX against an established leader like Hibernate. You have to realize the up hill battle some developers will face. BTW I am not endorsing JPOX per se, merely wishing there were some alternatives that could possibly make it past the institutional resistance.
BTW thank you for participating in this thread. It is nice to have an expert voice. I went to your site. I saw your benchmarks. Good stuff.
rick hightowercto of arcMindbloglinkedinFeb 20, 2008 · Lebon Bon Lebon
Well maybe you should spend some time on it. It seems like Hibernate is the de facto choice for many. I remember when Hibernate came out they were pretty direct with their thoughts about EJB CMP/CMR. It is hard to recommend something like JPOX against an established leader like Hibernate. You have to realize the up hill battle some developers will face. BTW I am not endorsing JPOX per se, merely wishing there were some alternatives that could possibly make it past the institutional resistance.
BTW thank you for participating in this thread. It is nice to have an expert voice. I went to your site. I saw your benchmarks. Good stuff.
rick hightowercto of arcMindbloglinkedinFeb 20, 2008 · Lebon Bon Lebon
Well maybe you should spend some time on it. It seems like Hibernate is the de facto choice for many. I remember when Hibernate came out they were pretty direct with their thoughts about EJB CMP/CMR. It is hard to recommend something like JPOX against an established leader like Hibernate. You have to realize the up hill battle some developers will face. BTW I am not endorsing JPOX per se, merely wishing there were some alternatives that could possibly make it past the institutional resistance.
BTW thank you for participating in this thread. It is nice to have an expert voice. I went to your site. I saw your benchmarks. Good stuff.
rick hightowercto of arcMindbloglinkedinFeb 20, 2008 · Lebon Bon Lebon
Hibernate supports customizing queries with plain old SQL. The support is great.
BTW Thanks for the comments, however, it would be nice to hear from some of the JPOX, OpenJPA, Cayenne guys. I'd love to hear what they think is so compelling about their ORM frameworks that would make someone who knows Hibernate want to switch.
I consider my Hibernate knowledge paid for at a dear price. I spent a lot of time reading online docs, forums, books, experimenting, prototyping and writing applications. I spent quite a bit of time tunning Hibernate apps to run faster, to use 2nd level cache, to use custom SQL, etc. I am not saying I would never switch or that Hibernate is the perfect tool for every application, but I've had a lot of success with it and the knowledge and experience is already bought and paid for.
Let's say OpenJPA was 20% better at legacy integration, and 10% better at performance (I don't know if it is or is not)... I am not sure this would be enough reason to swtich.
When I first started learning about JPA, I was not very happy with it but after working with it, reading the spec., etc. I find JPA refines the concepts in Hibernate and simplifies them... makes them more coherent. It took me a while to warm up to JPA but not that I have....
Is Hibernate the best JPA implementation?
rick hightowercto of arcMindbloglinkedinFeb 15, 2008 · Karlie Robinson
Good to hear. Seems like seam offers a lot. We don't use it yet, but it is integrated with Crank.
rick hightowercto of arcMindbloglinkedinFeb 15, 2008 · Karlie Robinson
Good to hear. Seems like seam offers a lot. We don't use it yet, but it is integrated with Crank.
rick hightowercto of arcMindbloglinkedinFeb 15, 2008 · Karlie Robinson
Good to hear. Seems like seam offers a lot. We don't use it yet, but it is integrated with Crank.
rick hightowercto of arcMindbloglinkedinFeb 14, 2008 · Peter Stofferis
Dice at this very moment....
16,000+ Java reqs
26 Groovy reqs
Seems I won't quit my day job anytime soon....
rick hightowercto of arcMindbloglinkedinFeb 14, 2008 · Peter Stofferis
I noticed the trend and welcome it.
rick hightowercto of arcMindbloglinkedinFeb 13, 2008 · Tony Colston
Feb 13, 2008 · Tony Colston
RE: I anticipate Groovy will enter the top 10 languages world wide next year and will be closing in on the top 5 at the end of 2010, but replace? no.
I agree with Graeme Rocher.
I really like Groovy. Before the adoption comes, sadly, the hype and religious fervor comes. Groovy will do quite well. It will be a long time before it can touch Java's popularity. I'd give it a 30% chance of being a dominant language on the JVM. (5 years, 10 years... never?)
Groovy is very productive and I really enjoy programming with it (GPath, builders, closures and more). It is a good mix of the features of Python with the environment of the JVM plus a lot more.
The lack of IDE support was the biggest obstacle to Groovy adoption and now there is excellent IDE support for Groovy. IntelliJ Groovy plugin support for Groovy makes Groovy a first class Java citizen and it is easy to mix and match Groovy and Java. Now the Eclipse plugin for Groovy has gone through several iterations of improvement and is fastly approaching this level of usability, when that happens a lot of doors will be opened for Groovy.
Groovy can be strongly typed, and yet is a dynamic language with modern language features. It truly takes the best features from Perl, Python, Ruby and mixes the together in a very Java-centric fashion. I have been working with it and really enjoy programming with it.
I don't think I will ever go back to Jython/Python.
rick hightowercto of arcMindbloglinkedinFeb 13, 2008 · Tony Colston
RE: I anticipate Groovy will enter the top 10 languages world wide next year and will be closing in on the top 5 at the end of 2010, but replace? no.
I agree with Graeme Rocher.
I really like Groovy. Before the adoption comes, sadly, the hype and religious fervor comes. Groovy will do quite well. It will be a long time before it can touch Java's popularity. I'd give it a 30% chance of being a dominant language on the JVM. (5 years, 10 years... never?)
Groovy is very productive and I really enjoy programming with it (GPath, builders, closures and more). It is a good mix of the features of Python with the environment of the JVM plus a lot more.
The lack of IDE support was the biggest obstacle to Groovy adoption and now there is excellent IDE support for Groovy. IntelliJ Groovy plugin support for Groovy makes Groovy a first class Java citizen and it is easy to mix and match Groovy and Java. Now the Eclipse plugin for Groovy has gone through several iterations of improvement and is fastly approaching this level of usability, when that happens a lot of doors will be opened for Groovy.
Groovy can be strongly typed, and yet is a dynamic language with modern language features. It truly takes the best features from Perl, Python, Ruby and mixes the together in a very Java-centric fashion. I have been working with it and really enjoy programming with it.
I don't think I will ever go back to Jython/Python.
rick hightowercto of arcMindbloglinkedinFeb 13, 2008 · Tony Colston
RE: I anticipate Groovy will enter the top 10 languages world wide next year and will be closing in on the top 5 at the end of 2010, but replace? no.
I agree with Graeme Rocher.
I really like Groovy. Before the adoption comes, sadly, the hype and religious fervor comes. Groovy will do quite well. It will be a long time before it can touch Java's popularity. I'd give it a 30% chance of being a dominant language on the JVM. (5 years, 10 years... never?)
Groovy is very productive and I really enjoy programming with it (GPath, builders, closures and more). It is a good mix of the features of Python with the environment of the JVM plus a lot more.
The lack of IDE support was the biggest obstacle to Groovy adoption and now there is excellent IDE support for Groovy. IntelliJ Groovy plugin support for Groovy makes Groovy a first class Java citizen and it is easy to mix and match Groovy and Java. Now the Eclipse plugin for Groovy has gone through several iterations of improvement and is fastly approaching this level of usability, when that happens a lot of doors will be opened for Groovy.
Groovy can be strongly typed, and yet is a dynamic language with modern language features. It truly takes the best features from Perl, Python, Ruby and mixes the together in a very Java-centric fashion. I have been working with it and really enjoy programming with it.
I don't think I will ever go back to Jython/Python.
rick hightowercto of arcMindbloglinkedinFeb 13, 2008 · Tony Colston
RE: I anticipate Groovy will enter the top 10 languages world wide next year and will be closing in on the top 5 at the end of 2010, but replace? no.
I agree with Graeme Rocher.
I really like Groovy. Before the adoption comes, sadly, the hype and religious fervor comes. Groovy will do quite well. It will be a long time before it can touch Java's popularity. I'd give it a 30% chance of being a dominant language on the JVM. (5 years, 10 years... never?)
Groovy is very productive and I really enjoy programming with it (GPath, builders, closures and more). It is a good mix of the features of Python with the environment of the JVM plus a lot more.
The lack of IDE support was the biggest obstacle to Groovy adoption and now there is excellent IDE support for Groovy. IntelliJ Groovy plugin support for Groovy makes Groovy a first class Java citizen and it is easy to mix and match Groovy and Java. Now the Eclipse plugin for Groovy has gone through several iterations of improvement and is fastly approaching this level of usability, when that happens a lot of doors will be opened for Groovy.
Groovy can be strongly typed, and yet is a dynamic language with modern language features. It truly takes the best features from Perl, Python, Ruby and mixes the together in a very Java-centric fashion. I have been working with it and really enjoy programming with it.
I don't think I will ever go back to Jython/Python.
rick hightowercto of arcMindbloglinkedinFeb 06, 2008 · Xelipe Zone
Feb 04, 2008 · Alessio Pace
There is no way Rails can take on Spring. I can prove it! Once and for all!!!!! Adapted from SOA facts (no copyright notice) and for Spring see http://soafacts.com/
Feb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
[quote=carlossg]Seam is too JBoss centric. Spring is more "open", at least for now, we'll see. That's an important point to have into account: community, users, support, ...[/quote]
This is just a bogus statement. I am not affiliated with JBoss/RedHat in anyway, so I am in a position to say that this is just bogus. Seam is no more a JBoss technology than Spring is an Interface 21 technology or Struts is an Apache technology. The Seam community is growing just like all communities have to grow. Christian et al have been working *very* hard on putting together resources for a very open community which you will hear about soon. These things just take time and effort to get going.
Seam also has killer integration with Spring. There is nothing stoping you from using the two in tandem in a completely non-JBoss environment. Please don't say stupid things without justifying your comments.
[/quote]
Bogus or not, that is a common perception so how do they overcome it. BTW I have a lot of respect for Carlos Sanchez... he is one of the smartest guys I've worked with and a real OS visionary so you may not agree with him, but you should at least hear him out.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
Great to hear from you Jim. It is good to hear from someone who has used Seam. Thanks for the insight and opinions. Thanks for the detailed comment.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
Great to hear from you Jim. It is good to hear from someone who has used Seam. Thanks for the insight and opinions. Thanks for the detailed comment.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
Great to hear from you Jim. It is good to hear from someone who has used Seam. Thanks for the insight and opinions. Thanks for the detailed comment.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
Great to hear from you Jim. It is good to hear from someone who has used Seam. Thanks for the insight and opinions. Thanks for the detailed comment.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
David,
Good to hear from you. It has been a while since we been in the trenches together. Hopefully soon....
Very good point. We took a look at Seam in March 2007 and came up with a similar conclusion for our project. It was nice, but integrating yet another framework into what we were already doing seemed like asking for trouble. Plus the Spring support seemed nascent (at the time).
RestFaces and Apache Orchestra seem like good choices as well.... We should talk more often. I did not know you guys did that... I will have to pick your brain.
I have spoke to some folks that do really like working with Seam. Someone just integrated Seam and Crank (out of the blue).
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
I agree they get that rep, whether its deserved or not. What can they do to change it? Also, Seam relies heavily on EJB3 or at least it did at first, which I think hurts it. I think if they advertised their Spring support more and added some Guice support, things would be better.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
I agree they get that rep, whether its deserved or not. What can they do to change it? Also, Seam relies heavily on EJB3 or at least it did at first, which I think hurts it. I think if they advertised their Spring support more and added some Guice support, things would be better.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
I agree they get that rep, whether its deserved or not. What can they do to change it? Also, Seam relies heavily on EJB3 or at least it did at first, which I think hurts it. I think if they advertised their Spring support more and added some Guice support, things would be better.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
I agree they get that rep, whether its deserved or not. What can they do to change it? Also, Seam relies heavily on EJB3 or at least it did at first, which I think hurts it. I think if they advertised their Spring support more and added some Guice support, things would be better.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
I work with people who think that. I also work with folks who think JSF is quite natural. We do fairly complex, feature rich webapplicatoins and its hard to imagine doing these apps without JSF.
I teach JSF classes, Spring MVC classes and in the past taught Struts classes (I also write courseware which is painful to do). I find that the students pick up JSF the fastest. JSF works best when you are building an application with rich features. If your webapplication is more like a website and less like an application than you are better off using something else. Plust JSF forces some behavior on your apps, if you are not happy with that behavior or can't abide by it, then JSF is not a good fit (When that happens, I use Spring MVC). However, I think there is a vast market for JSF based applications.
I recently wrote a series highlighting JSF development and how easy it is: JSF Tutorial Part 1, JSF Tutorial Part 2.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
I work with people who think that. I also work with folks who think JSF is quite natural. We do fairly complex, feature rich webapplicatoins and its hard to imagine doing these apps without JSF.
I teach JSF classes, Spring MVC classes and in the past taught Struts classes (I also write courseware which is painful to do). I find that the students pick up JSF the fastest. JSF works best when you are building an application with rich features. If your webapplication is more like a website and less like an application than you are better off using something else. Plust JSF forces some behavior on your apps, if you are not happy with that behavior or can't abide by it, then JSF is not a good fit (When that happens, I use Spring MVC). However, I think there is a vast market for JSF based applications.
I recently wrote a series highlighting JSF development and how easy it is: JSF Tutorial Part 1, JSF Tutorial Part 2.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · Karlie Robinson
I work with people who think that. I also work with folks who think JSF is quite natural. We do fairly complex, feature rich webapplicatoins and its hard to imagine doing these apps without JSF.
I teach JSF classes, Spring MVC classes and in the past taught Struts classes (I also write courseware which is painful to do). I find that the students pick up JSF the fastest. JSF works best when you are building an application with rich features. If your webapplication is more like a website and less like an application than you are better off using something else. Plust JSF forces some behavior on your apps, if you are not happy with that behavior or can't abide by it, then JSF is not a good fit (When that happens, I use Spring MVC). However, I think there is a vast market for JSF based applications.
I recently wrote a series highlighting JSF development and how easy it is: JSF Tutorial Part 1, JSF Tutorial Part 2.
rick hightowercto of arcMindbloglinkedinFeb 01, 2008 · gumnaam cox
Thanks. Just what the doctor ordered...
rick hightowercto of arcMindbloglinkedinJan 30, 2008 · Lebon Bon Lebon
It is an interesting announcement.
Thinking out loud....
I read that the BZ Research says that Tomcat more than 60%... WOW!
Rod says on his blog that "Ninety-three (93) percent Spring users are also running their applications, many of them mission critical, on Tomcat."
The last shop I worked with started using JSF, Spring, and Hibernate on 30 some apps and hired me and two other ArcMinders for 18 months to help. They deployed on WebSphere and Tomcat (mostly they deployed on WebSphere, but develop with Tomcat). Two other companies I work with before that deployed on WebLogic, but the developers worked with Tomcat (but not all)--they both still use WebLogic. One of the current shops I am working with use JSF, Spring, JPA, and Spring MVC develop with maven/jetty using jetty plugin and then deploy on JBoss for integration, qa and production. Same with a company I worked with two years ago. I also ran into at least three companies who were using Oracle AS while training.
Okay... I work with a lot of companies (training and consulting).... I don't see too many deploying to Tomcat in production. I see a lot of developers using Tomcat for development, but only see about 10% or so deploying to it in production.
Of course, JBoss uses Tomcat for the web container... Also doesn't WebSphere use a modified version of Tomcat for its web container. Would they count as Tomcat instances? I guess I should read the study.
sorry for this...
http://www.indeed.com/jobtrends?q=tomcat%2C+jboss%2C+weblogic%2C+websphere&l=
http://www.indeed.com/jobtrends?q=tomcat+java%2C+jboss+java%2C+weblogic+java%2C+websphere+java&l=
I guess I am a bit skeptical of the report because it does not reflect the reality that I see when I am out training and consulting.
Nothing against Tomcat, I like it well enough. (I prefer the jetty maven plugin for development, but used Tomcat for years before that as a quick and easy web container.) This is not a technical argument against Tomcat. In fact it is an observation not an argument at all.
Don't write me and tell me how great Tomcat is.... When I have seen Tomcat used in production, it worked well enough for the apps we worked with.
Given the choice... many developer would prefer to work with Tomcat to other application servers.
Spring + JSF + JPA/Hibernate is still my dev frameworks of choice.
rick hightowercto of arcMindbloglinkedinJan 30, 2008 · Lebon Bon Lebon
I think it would be great to have a standard, powerful dependency injection framework that ships with Java. The IoC framework should have the power of Spring 2.5/Guice style injection.
Why not add a standard AOP lib/framework as well?
rick hightowercto of arcMindbloglinkedinJan 30, 2008 · Lebon Bon Lebon
Agreed. However I think your book and the ones that follow on Struts 2 will go a long way to keep Struts alive and give a lot of Struts-based application a way forward without drastic switching since Struts 2 is backwards compatible with Struts 1.x. Struts is still the 800 pound gorilla and its nice to have an upgrade path to an innovative framework like Struts 2. I wish you the best.
rick hightowercto of arcMindbloglinkedinJan 30, 2008 · Lebon Bon Lebon
Agreed. However I think your book and the ones that follow on Struts 2 will go a long way to keep Struts alive and give a lot of Struts-based application a way forward without drastic switching since Struts 2 is backwards compatible with Struts 1.x. Struts is still the 800 pound gorilla and its nice to have an upgrade path to an innovative framework like Struts 2. I wish you the best.
rick hightowercto of arcMindbloglinkedinJan 30, 2008 · Lebon Bon Lebon
Agreed. However I think your book and the ones that follow on Struts 2 will go a long way to keep Struts alive and give a lot of Struts-based application a way forward without drastic switching since Struts 2 is backwards compatible with Struts 1.x. Struts is still the 800 pound gorilla and its nice to have an upgrade path to an innovative framework like Struts 2. I wish you the best.
rick hightowercto of arcMindbloglinkedinJan 29, 2008 · Lebon Bon Lebon
Congrats on the book Ian! I am sure that was a lot of hard work.
Since this is the first Struts 2 book it will be interesting to see what its Sales Rank is to gauge the interests in Struts 2.
For example, Java Persistence with Hibernate is the second most selling Java book and JSF Core is the third most selling Java book on bookpool so it would appear that there is a lot of interest in Hibernate/JPA and JSF.
Here are the Amazon Sales Ranks for JSF books, this Struts 2 and the only book focused on Spring MVC on Amazon:
JSF Core<> 8,922Struts 2 by Ian40,523JSF Complete Ref41,052Spring MVC156,302(Lower sales rank implies more sales. As a comparison, the Hibernate book has a sales rank of 4,578.)Spring MVC is covered well in a few of the Spring books so its low sales rank is somewhat expected. (plus it has been out the longest of the 4 mentioned). The JSF books are older and their is a lot of competition of JSF books (being more than one and at least two are in their second edition).
It looks like Struts 2 is off to a good start, but has a ways to catch JSF. I remember when classic Struts had three of the top ten bestselling Java books on Amazon and bookpool. Do you think Struts 2 will ever be pervasive as Struts 1?
rick hightowercto of arcMindbloglinkedinJan 29, 2008 · Lebon Bon Lebon
RE: This is a silly comparison
Yes in a sense JSF and Swing are apples and oranges as one is for the rich clients and one is for webapps. Yet the GUI component model (composite design pattern, events) is similar.
RE: JSF is a server side web framework, built on Servlets and JSP
JSF is not built on Servlets and JSP. JSF is seperate from Servlets and JSP. There are integration pieces that ship with JSF that allow it to operate with Servlets and JSP. The JSF taglibs bolt JSF to JSP in a most uncomfortable fasion. JSF is much better without JSP. I would say that JSF was built with web applications in mind, but it is not inherently tied to Servlets (works with Portlets) or JSP (works better with Facelets).
The JSF component model has nothing to do with JSP. You can replace JSPs with Facelets and be better for it in the end.
The real idea was not to compare JSF to Swing, but to show that Swing is an established technology and now so is JSF based on job demand.
JSF is more similar to AWT or Swing than Struts, or Spring MVC.
I agree that JSF is best compared to Wicket, Echo and Tapestry, and its job demand eclipse those rather easily. Although many feel Wicket is gaining some steam.
Do you think Wicket will give JSF a run for the money in market share? I've heard a lot of folks say some pretty nice things about Wicket.
rick hightowercto of arcMindbloglinkedinJan 29, 2008 · Lebon Bon Lebon
RE: This is a silly comparison
Yes in a sense JSF and Swing are apples and oranges as one is for the rich clients and one is for webapps. Yet the GUI component model (composite design pattern, events) is similar.
RE: JSF is a server side web framework, built on Servlets and JSP
JSF is not built on Servlets and JSP. JSF is seperate from Servlets and JSP. There are integration pieces that ship with JSF that allow it to operate with Servlets and JSP. The JSF taglibs bolt JSF to JSP in a most uncomfortable fasion. JSF is much better without JSP. I would say that JSF was built with web applications in mind, but it is not inherently tied to Servlets (works with Portlets) or JSP (works better with Facelets).
The JSF component model has nothing to do with JSP. You can replace JSPs with Facelets and be better for it in the end.
The real idea was not to compare JSF to Swing, but to show that Swing is an established technology and now so is JSF based on job demand.
JSF is more similar to AWT or Swing than Struts, or Spring MVC.
I agree that JSF is best compared to Wicket, Echo and Tapestry, and its job demand eclipse those rather easily. Although many feel Wicket is gaining some steam.
Do you think Wicket will give JSF a run for the money in market share? I've heard a lot of folks say some pretty nice things about Wicket.
rick hightowercto of arcMindbloglinkedinJan 29, 2008 · Lebon Bon Lebon
RE: This is a silly comparison
Yes in a sense JSF and Swing are apples and oranges as one is for the rich clients and one is for webapps. Yet the GUI component model (composite design pattern, events) is similar.
RE: JSF is a server side web framework, built on Servlets and JSP
JSF is not built on Servlets and JSP. JSF is seperate from Servlets and JSP. There are integration pieces that ship with JSF that allow it to operate with Servlets and JSP. The JSF taglibs bolt JSF to JSP in a most uncomfortable fasion. JSF is much better without JSP. I would say that JSF was built with web applications in mind, but it is not inherently tied to Servlets (works with Portlets) or JSP (works better with Facelets).
The JSF component model has nothing to do with JSP. You can replace JSPs with Facelets and be better for it in the end.
The real idea was not to compare JSF to Swing, but to show that Swing is an established technology and now so is JSF based on job demand.
JSF is more similar to AWT or Swing than Struts, or Spring MVC.
I agree that JSF is best compared to Wicket, Echo and Tapestry, and its job demand eclipse those rather easily. Although many feel Wicket is gaining some steam.
Do you think Wicket will give JSF a run for the money in market share? I've heard a lot of folks say some pretty nice things about Wicket.
rick hightowercto of arcMindbloglinkedinJan 29, 2008 · Lebon Bon Lebon
RE: This is a silly comparison
Yes in a sense JSF and Swing are apples and oranges as one is for the rich clients and one is for webapps. Yet the GUI component model (composite design pattern, events) is similar.
RE: JSF is a server side web framework, built on Servlets and JSP
JSF is not built on Servlets and JSP. JSF is seperate from Servlets and JSP. There are integration pieces that ship with JSF that allow it to operate with Servlets and JSP. The JSF taglibs bolt JSF to JSP in a most uncomfortable fasion. JSF is much better without JSP. I would say that JSF was built with web applications in mind, but it is not inherently tied to Servlets (works with Portlets) or JSP (works better with Facelets).
The JSF component model has nothing to do with JSP. You can replace JSPs with Facelets and be better for it in the end.
The real idea was not to compare JSF to Swing, but to show that Swing is an established technology and now so is JSF based on job demand.
JSF is more similar to AWT or Swing than Struts, or Spring MVC.
I agree that JSF is best compared to Wicket, Echo and Tapestry, and its job demand eclipse those rather easily. Although many feel Wicket is gaining some steam.
Do you think Wicket will give JSF a run for the money in market share? I've heard a lot of folks say some pretty nice things about Wicket.
rick hightowercto of arcMindbloglinkedinJan 29, 2008 · Lebon Bon Lebon
Kito suggested I change the search from JSF and java to (jsf or "JavaServer Faces" or "Java Server Faces") and java.
When I do that, it shows that JSF passed Swing in April of last years as the GUI component model with the most demand. Looks like its been neck and neck since then.
[img_assist|nid=543|title=JSF passes Swing|desc=|link=none|align=left|width=540|height=300]
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
True. I think the battle is far from over. I know I have had to use EJB3 already. Most places I work with use Spring, but one company used EJB3. It was not that bad. It was simple and fit the application okay. There were some things we wanted to build that would have been included in Spring or at least easier in Spring. It was an okay experience.
I am not a fan of EJB3, but much prefer to EJB2.x and before.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
True. I think the battle is far from over. I know I have had to use EJB3 already. Most places I work with use Spring, but one company used EJB3. It was not that bad. It was simple and fit the application okay. There were some things we wanted to build that would have been included in Spring or at least easier in Spring. It was an okay experience.
I am not a fan of EJB3, but much prefer to EJB2.x and before.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
True. I think the battle is far from over. I know I have had to use EJB3 already. Most places I work with use Spring, but one company used EJB3. It was not that bad. It was simple and fit the application okay. There were some things we wanted to build that would have been included in Spring or at least easier in Spring. It was an okay experience.
I am not a fan of EJB3, but much prefer to EJB2.x and before.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
True. I think the battle is far from over. I know I have had to use EJB3 already. Most places I work with use Spring, but one company used EJB3. It was not that bad. It was simple and fit the application okay. There were some things we wanted to build that would have been included in Spring or at least easier in Spring. It was an okay experience.
I am not a fan of EJB3, but much prefer to EJB2.x and before.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · admin
Wow! This will be very nice. Writing example programs that use Maven can be a chore. The speed improvements will help a lot of people.
Thanks Don Brown!
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
BOO! Come on. Tomcat is JEE. JMS is JEE. JTA is JEE. Don't throw the baby out with the bath.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
BOO! Come on. Tomcat is JEE. JMS is JEE. JTA is JEE. Don't throw the baby out with the bath.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
BOO! Come on. Tomcat is JEE. JMS is JEE. JTA is JEE. Don't throw the baby out with the bath.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
RE: JEE gave them the common lever to stand on...
BINGO! JCP is important (not perfect) but where would we be without it? Well put! Well put indeed.
EJB was not perfect, but even Rod was pro-EJB in his first book.
The world of JEE does well because we have the right balance of innovative open source projects and standards.
If EJB3 would have been better, would Spring market share for job demand be less?
I think the answer is probably yes. To what degree, I don't know. (I am still very pro-Spring and use it daily.)
Spring and Hibernate infused some life into JEE. The relationship is reciprocal.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
RE: JEE gave them the common lever to stand on...
BINGO! JCP is important (not perfect) but where would we be without it? Well put! Well put indeed.
EJB was not perfect, but even Rod was pro-EJB in his first book.
The world of JEE does well because we have the right balance of innovative open source projects and standards.
If EJB3 would have been better, would Spring market share for job demand be less?
I think the answer is probably yes. To what degree, I don't know. (I am still very pro-Spring and use it daily.)
Spring and Hibernate infused some life into JEE. The relationship is reciprocal.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
RE: JEE gave them the common lever to stand on...
BINGO! JCP is important (not perfect) but where would we be without it? Well put! Well put indeed.
EJB was not perfect, but even Rod was pro-EJB in his first book.
The world of JEE does well because we have the right balance of innovative open source projects and standards.
If EJB3 would have been better, would Spring market share for job demand be less?
I think the answer is probably yes. To what degree, I don't know. (I am still very pro-Spring and use it daily.)
Spring and Hibernate infused some life into JEE. The relationship is reciprocal.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
This is true. The charts are clearly labeled are they not? The first two graphs are absolute, the last one is relative.
The first one show JSF job demand catching up to Swing job demand.
The second shows JSF does well against everything but Struts.
The third shows that Struts growth is flat.
I mentioned that Struts was number 1, and explained how there might be problems with the data which may show Struts 2 and Spring MVC lower than they actually are.
I think the coverage is somewhat balanced.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
This is true. The charts are clearly labeled are they not? The first two graphs are absolute, the last one is relative.
The first one show JSF job demand catching up to Swing job demand.
The second shows JSF does well against everything but Struts.
The third shows that Struts growth is flat.
I mentioned that Struts was number 1, and explained how there might be problems with the data which may show Struts 2 and Spring MVC lower than they actually are.
I think the coverage is somewhat balanced.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
This is true. The charts are clearly labeled are they not? The first two graphs are absolute, the last one is relative.
The first one show JSF job demand catching up to Swing job demand.
The second shows JSF does well against everything but Struts.
The third shows that Struts growth is flat.
I mentioned that Struts was number 1, and explained how there might be problems with the data which may show Struts 2 and Spring MVC lower than they actually are.
I think the coverage is somewhat balanced.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
You are of course right Rick. I am going to change the title to reflect reality.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
You are of course right Rick. I am going to change the title to reflect reality.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
You are of course right Rick. I am going to change the title to reflect reality.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
You are of course right Rick. I am going to change the title to reflect reality.
rick hightowercto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
Great post! I will follow this series of posts. A little Groovy a day is a good way to learn the bits I am missing. Thanks.
rick hightower
cto of arcMindbloglinkedinJan 28, 2008 · Guillaume Laforge
Great post! I will follow this series of posts. A little Groovy a day is a good way to learn the bits I am missing. Thanks.
rick hightower
cto of arcMindbloglinkedinJan 28, 2008 · Lebon Bon Lebon
I agree with you about EJB3 but not JEE:
Here is an excerpt from a post I wrote 1.5 years ago:
Having endured building applications with EJB 2.x and Struts, using Spring and Hibernate was like a breath of fresh air. Development was easier and less time was spent working around the limitations of the platform.
J2EE has good ideas, which inspired a lot of additional ideas. This evolution led to innovative and productive practices outside of the JCP.
The JCP has had some very good JSRs, but you have to admit there have been some real stinkers.
EJB in general, except as a learning experience, is generally viewed as a failure. The real problem was not just EJB but the misapplications of EJB. This was widespread as it was promoted with the J2EE Blueprint, not to mention the misapplication of JTA, and more features of J2EE. Not to say that applications can't benefit from JTA and EJB, it's just that many, many Web applications don't need them.
EJB 3.0 is much better than EJB 2.x. If you compare EJB3 to an older version of EJB, EJB3 is a boon; however, if you compare EJB3 to Spring and Hibernate, it stinks.
The related OR (Object Relation) Persistent API does not have a criteria API specified; any persistent API that does not define a criteria API is not finished.
The AOP support in EJB3 is broken. EJB3 has a method interceptor, but no pointcuts. In addition, the method interceptors are declared and imported with class-level annotations. This effectively tightly couples the class to the method interceptors that decorate it (Can you smell the bad odor?).
Rod Johnson mentioned thess same problems about EJB3 Method Interceptors at a recent Java enterprise conference (in his talk "Are We There Yet") and went on to mention many limitations on the @Resource style of DI, the absence of FactoryBeans, post processors, Constructor Injection, lists/maps, and a lot of the features Spring developers know and love are just missing. The EJB3 JSR members did not look at any of the prior art in this space and created their own limited version of what was already available.
I've heard some call EJB3 a dumbed-down version of what is available by using Spring and Hibernate. "EJB3 is Spring and Hibernate's stupid cousin" is frequently echoed.
After three years of deliberation, the JCPs delivered EJB3, which is inferior to de facto standards. Many parts of EJB3 are a big step backward from Spring, and, to many, EJB3 is broken. As Bruce Tate says about EJB3: "Don't make me eat the elephant again."
It's not just the persistent API and the AOP support that's broken in EJB3, it's also the random use of annotations, another misguided effort. The idea of annotations is good. The implementation of the annotations ruins some of the principles of the POJO model; namely, it ties your Java classes through a compile-time dependency to the standard API you're using and to any value-add annotations the vendor supports. Now why would vendors like this approach? Hmmm...I wonder. (Hint: Follow the money!)
In that question lies the real problem with the JCP. The JCP is heavily influenced by vendors that have "business need(s) or corporate agenda(s)." Parts of the enterprise Java community is innovative, parts stink, but there are many parts.
http://jdj.sys-con.com/read/216307.htm
rick hightowercto of arcMindbloglinkedinJan 25, 2008 · Lebon Bon Lebon
Yeah this would be a great feature. Faster turnaround. Back in the day (if my memory serves me correct and I imagine still), Resin could scan a source directory and automatically deploy Java source files in a web application. It was not perfect. This gave the Java app more of a PHP feel for rapid-redeploy. It worked pretty well.
That would be great. How does Tapestry do that?
Or... they could take the money from JRuby support budget and write it themseleves. Oh wait. Flame bait. Sorry.
Perhaps this could make it into Java 7.
I use the maven jetty plugin and it starts up darn quick even on rather large apps. Or maybe, I have been conditioned to slowness.
Thinking about this more... Wow wouldn't it be great to take this out as an argument against Java? It kind of takes the steam out of a lot of arguments if this support was built-in to the JVM. Good post Matt.
Seems like this should be a much higher priority than a lot of other things.
rick hightowercto of arcMindbloglinkedinJan 25, 2008 · Lebon Bon Lebon
I saw this one coming. Nice.
rick hightowercto of arcMindbloglinkedinJan 24, 2008 · Peter Stofferis
Me too. Just wanted to make sure I didn't miss anything.
rick hightowercto of arcMindbloglinkedinJan 24, 2008 · Peter Stofferis
Me too. Just wanted to make sure I didn't miss anything.
rick hightowercto of arcMindbloglinkedinJan 23, 2008 · admin
Jan 23, 2008 · Peter Stofferis
Jan 23, 2008 · Peter Stofferis