Adam Bien's Weblog
kenai.com is dead - long live kenai (under different name)
Even got this email:
"In an effort to get information out to the Kenai community quickly, while trying to manage the integration of our two companies, I think we did a poor job at communicating our plans for Kenai.com to you. I would like to remedy that now. Our strategy is simple. We don't believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down kenai.com and focus our efforts on java.net as the hosted development community. We are in the process of migrating java.net to the kenai technology. This means that any project currently hosted on kenai.com will be able to continue as you are on java.net. We are still working out the technical details, but the goal is to make this migration as seamless as possible for the current kenai.com projects. So in the meantime I suggest that you stay put on kenai.com and let us work through the details and get back to you later this month.
Thanks for your feedback and patience."
These are actually great news. Hopefully all the kenai.com infrastructure like mercurial (subversion isn't fun), jira and hudson will be supported by java.net. So I'm waiting with the migration of "Real World Java EE Patterns" project and will even commit some more content soon. The great story about mercurial: the whole repository with history etc. sits on my machine and can be pushed wherever I want :-). kenai.com is/was an interesting platform - suitable not only for opensource projects.
Posted at 02:07PM Feb 06, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[0]
[my tweets] 
Rss My book: Real World Java EE - Rethinking Best Practices
Object Pooling Can Be Still Useful - For Entirely Different Reasons
Pooling was initially introduced as a tuning action for the slow performance of object creation and garbage collection in particular. On a modern JVM > 1.4 pooling is no more needed for the optimization of memory management in a typical business application. It can even have a negative effect on the garbage collector performance. In special cases, like creating millions of instances in every method call, it could still pay off.
Instance pooling, however is still interesting for objects with slow custom "post construction". In some cases you want to inject some dependencies after the object creation, read some configuration etc. This can be slow and doesn't have to be performed over and over again. In such cases object pooling will improve the overall performance.
Instead of prematurely optimize your application, I would rather build the simplest possible thing and measure the performance continuously (e.g. with VisualVM). In most cases you will be surprised where the actual bottlenecks actually are.
Posted at 09:00AM Feb 02, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[2]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
Do We Need Stateless Session Bean Pooling?
Pooling is still mentioned in the EJB 3.1 / Java EE 6 specification. The question is: do you have to care? The answers are:
- Pooling is not a requirement, it is just an assumption: "...Since stateless session bean instances are typically pooled, the time of the client’s invocation of the create method need not have any direct relationship to the container’s invocation of the PostConstruct/ejbCreate method on the stateless session bean instance..."[EJB 3.1 spec, page 78]
- EJB container can either pool the instances or create a new one for each request
- The most important thing is, that every transaction (often request), gets an independent instance. Then you don't have to care about low level locking mechanisms. This can be achieved with or without (=creating a new instance for each request) pooling.
- Pooling is no more needed in modern JVMs for performance reasons in general. This, however, is highly dependent on the JVM and garbage collector configuration.
- With pools you can throttle the concurrency, because most (all I know) application servers allow you the configuration of max number of instances. You can control the concurrency of every bean type (Boundary) in a fine grained way. This is important for the avoidance of DoS attacks and dealing with legacy resources.
Posted at 11:11AM Jan 15, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[11]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
What is the difference between pooling and caching?
The difference is simple. Pooling is appropriate if you don't care about the internal state of a particular class / type. Pooling is mainly motivated by technical reasons like performance, latency or memory optimizations.
Caching is all about state. You want to retain the state for performance reasons and store (cache) it in objects between calls. So instead loading the state from the database in every request, you could cache the data between requests in valid objects.
Posted at 11:03AM Jan 11, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[1]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
Java EE 6 And The JCP Stuff - Perfect For Lazy Developers
Clarification: all developers should be lazy :-).
Java EE (6) is an abstraction of existing products (Hibernate, TopLink, Glassfish, JBoss, Geronimo, Tomcat+, ...) and API-implementations. So if you develop Java EE 6 applications, you can start with the spec and dig into the implementation details as needed. If you are using e.g. Glassfish application server, EclipseLink (JPA), Equinox or Felix(OSGi), RedHat Weld (CDI) ... are working for you - but you don't have usually to care about the details. The best of all - if you don't like a certain implementation - you can change your application server. After learning plain Java EE (5 or 6 - both are similar), you will be able to work with all application server vendors with minimal learning curve. This year I would expect at least 4 Java EE 6 server implementations: Glassfish 3 (is done), JBoss 6 (not yet), Geronimo (announced), Resin (only parts - but sounds interesting).Java EE 5 is already implemented by 14 different servers - I would expect at least the same support for Java EE 6 in longer term. Btw. plain Java EE 5 spec together with JDK 1.6 was sufficient for >95% of all cases in my past projects in last 3 years. Actually the majority of the projects was absolutely portable - without any vendor-specific extensions. With Java EE 6 you will gain even greater vendor independence - Servlet 3, JPA 2, CDI, EJB 3.1, JSF 2 standardized a lot more vendor specific stuff. If you are not lazy - here are some other arguments for switching.
Posted at 03:14PM Jan 08, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[2]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
What Is The Relation Between JSR-299 and JSR-330 In Java EE 6? Do We Need Two DI APIs?
There was/is a lot of confusion, as JSR-330 (Dependency Injection for Java) led by Rod Johnson (SpringSource) and Bob Lee (Google Inc.) became a part of Java EE 6. JSR-330 is very simplistic. It comes with own few annotations from the package: javax.inject. The package contains the following elements: Inject, Qualifier, Scope, Singleton, Named and Provider. Its the definition of the basic dependency injection semantics.
@Named is not recommended and should be used only for integration with legacy code:
"The use of @Named as an injection point qualifier is not recommended, except in the case of integration with legacy code that uses string-based names to identify beans."[3.11 The qualifier @Named at injection points, JSR-299 Spec, Page 32] The relation between JSR-299 and JSR-330 is comparable to the relation between JPA and JDBC. JPA uses internally JDBC, but you can still use JDBC without JPA. In Java EE 6 you can just use JSR-330 for basic stuff, and enhance it on demand with JSR-299. There is almost no overlap in the practice. You can even mix JSR-299 / JSR-330 with EJB 3.1 - to streamline your application.
Posted at 10:12AM Jan 07, 2010 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[4]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
Real World Java EE Patterns - Rethinking Best Practices Book Is Back On Amazon.de
"Real World Java EE Patterns - Rethinking Best Practices" book is available again on amazon.de (was somehow sold out):
Posted at 02:59PM Dec 19, 2009 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[4]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
EJB 3.1 Killed The Backing Beans Or JSF 2, EJB 3.1, JSR-330 - The Perfect Synergy
A Stateless Session Bean with the JSR-330 @Named annotation:
@Stateless
@Named("helloService")
public class HelloService {
@EJB ClockService clockService;
public String getHello(){
return "Hello from EJB / CDI: " + clockService.currentTime();
}
}
can be directly referenced in the JSF 2:
<h:body>
<h:form>
<h:outputLabel value="#{helloService.hello}"/>
</h:form>
</h:body>
You don't need the Backing Bean anymore - but you can still use it.
The project (JSF2EJB3CDI) was implemented in few minutes with NetBeans 6.8, tested with Glassfish v3 and pushed into: http://kenai.com/projects/javaee-patterns/. The entire WAR (JSF 2.0 , EJB 3.1, CDI) is 8 kB small. The initial deployment took 1.516 ms seconds, and was twice as slow, as in the Java EE 6 observer example:
INFO: Initializing Mojarra 2.0.2 (FCS b10) for context '/JSF2EJB3CDI'
INFO: Loading application JSF2EJB3CDI at /JSF2EJB3CDI
INFO: JSF2EJB3CDI was successfully deployed in 1,516 milliseconds.
Posted at 09:00AM Dec 18, 2009 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[13]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
Java EE 6 Observer Pattern / Events With CDI (JSR-299/JSR-330) and EJB 3.1
1. You will have to define an event class first. It can be any POJO you like:
2. An event has to be fired by an injected javax.enterprise.event.Event class. It can be injected into an EJB 3.1:
@Named("messenger")
@Stateless
public class HelloMessenger {
@Inject Event<HelloEvent> events;
public void hello(){
events.fire(new HelloEvent("from bean " + System.currentTimeMillis()));
}
}
3. The event can be consumed by another Session Bean / managed bean. You only have to use the @Observes annotation:
@Stateless
public class HelloListener {
public void listenToHello(@Observes HelloEvent helloEvent){
System.out.println("HelloEvent: " + helloEvent);
}
}
4. You can access the EJB 3.1 directly - without any backing beans. You only have to use the name (messenger) from the @Named annotation in the JSF 2.0 page and bind the action to the method (hello()) name:
<h:body>
<h:form>
<h:commandButton value="Fire!" action="#{messenger.hello}"/>
</h:form>
[...]
The project (CDIEJB3Events) was implemented in few minutes with NetBeans 6.8, tested with Glassfish v3 and pushed into: http://kenai.com/projects/javaee-patterns/. The entire WAR (JSF 2.0 , EJB 3.1, CDI) is 8 kB small. The initial deployment took (897 ms):
INFO: Initializing Mojarra 2.0.2 (FCS b10) for context '/CDIEJB3Events'
INFO: Loading application CDIEJB3Events at /CDIEJB3Events
INFO: CDIEJB3Events was successfully deployed in 897 milliseconds.
Posted at 09:00AM Dec 17, 2009 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[3]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
9 Reasons Why Java EE 6 Will Save Real Money - Or How To Convince Your Management
- Prototyping: in general (Enterprise) Java projects start with evaluation which frameworks to use. This can take from few hours, to several months (although these times are hopefully over). Java EE 6 comes with “one stop shopping”. You can download Java EE 6 with the IDE (eclipse, netbeans, jdeveloper and commercial IntelliJ) and just start hacking. You can install and develop a prototype in minutes. The package sizes are small e.g. NetBeans 6.8 with Glassfish v3, Derby and all required plugins take 146 MB Eclipse with Glassfish / Java EE tooling is also small: 147 MB for MacOS X.
- Development: Java EE 6 implementations are lightweight. Glassfish comes with 30 MB for the Web Profile, or 75 MB (everything). Deployment takes only few milliseconds. Incremental deployment is supported out-of-the-box. You only have to save the file. The other application servers (JBoss, Caucho's Resin, Geronimo / openEJB) are expected to be similarly lightweight. Because the majority of the libraries and frameworks is already located on the server, you have only to deploy the application code. The deployment archive contains mainly your application code and is so surprisingly small - a kilobyte deployment is possible.
- Production: Glassfish, JBoss, Geronimo and probably the others do follow the opensource model. You can decide whether you need commercial support or not. You can start small - then scale.
- Licensing: Java EE 5/6 applications are surprisingly portable - there are no more vendor specific deployment descriptors required. You can easily port your application from one server to another. It is actually the matter of copying of an WAR / EAR archive from one directory to another. We actually did it in the past to ensure application server independence. These are is possible since Java EE 5 and so 2006. Knowing that, you have a good position to be able to get better offers for licensing / support. You are not dependent on a particular vendor and can pick the most interesting one.
- Training / Knowledge: You “only” have to learn Java EE 6 and so its API - the start is easy. This knowledge is generic and can be applied to any application server out there. If you know Java EE 5 already - you will love Java EE 6 :-).
- Portability: ancient legacy J2EE 1.X projects are easy to migrate to Java EE 5/6. Java EE 6 containers still have to support the old programming model. Porting your application is fun - it mainly consists of deleting superfluous artifacts. J2EE 1.X and Java EE 6 components can even peacefully coexist.
- Adoption: Java EE 6 was developed by the JCP. It wasn’t developed by Sun, rather than by the community and all major players. IBM, Oracle, SAP, Red Hat, Google, even Spring Source / VMWare (Rod Johnson) contributed an API. The Java EE 6 spec is expected to be adopted as well as Java EE 5. There were 14 different certified Java EE 5 servers.
- Freedom of Choice / Investment Protection: because Java EE 6 was developed by the community (BEA, IBM, SAP, Oracle Sun, SpringSource etc.), and not a single vendor it will remain stable. It is impossible for one entity to change / break the spec, an API. This is a huge advantage of Java / Java EE over other languages. You can still run your ancient J2EE 1.4 apps on your shiny Java EE 5/6 server without any modifications.
- Risk Mitigation / Plan B: Java EE APIs are not intrusive and heavily based on annotations and Convention over Configuration / Dependency Injection principles. In case for some reason Java EE 6 will not work for you - the migration to the alternatives like Spring is relatively easy. Both components models (EJBs, CDI / Spring) are rather similar.
Posted at 09:44AM Dec 16, 2009 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices | Kommentare[14]
[my tweets] Rss My book: Real World Java EE - Rethinking Best Practices
