12.16.06
Posted in Java at 1:56 am by skoobi
Here is a funny, satirical comment from Daniel Spiewak on Java code produced by different people (student, professor, developer…).
We can probably draw a parallel with the funny quotes about Java I previously cited.
My opinion is that every Java developer is aware that everything he does is far more complex than it should be. However, abstraction is the key foundation of Computer Science, and most people agree that C is a good abstraction over ASM and Java/.Net are good abstractions over C. So, what is the limit of abstraction ? Are frameworks, Design Patterns, Factories and new abstractions all over the place a good thing ?
What is sure is that people who start using frameworks and libraries use even more of them. So, even if it is not a perfect solution, there is something great in that.
Permalink
12.11.06
Posted in Java, Web Development at 12:14 pm by skoobi
Sun just announced J2SE 6 and many java bloggers are relaying the information..
Something important for the web development community in this release is the support for scripting languages. In fact, the trend, that has been started with Java Hotswap, is to create tools that allow Web Frameworks to be more productive for developers.
Indeed, developers are tired of the develop / build / deploy cycle, and would prefer to work with the PHP-like develop / reload in browser development cycle. Well, scripting is a step in that direction, and would allow to :
- Keep the domain layer as strongly-typed POJOs, that are unit-tested and constantly refactored to keep a good design.
- Write the Web Controllers (the C in MVC) in any scripting language (the view being written in any already-existing templating language, such as JSP or Freemarker). This allows rapid development and since the view is hardly reusable anyways, it’s better to throw it away and recreate something from scratch when needed.
Efforts toward that direction have already been started, as relayed by these few blog entries and articles :
So, now the next step is to have universal support for that kind of development, and have better IDE support that will allow refactoring both in the scripted controllers and the view (JSP, Freemarker..). In fact, there is currently no way to make sure nothing is broken besides writing functional (Selenium, Canoo Webtest, HttpUnit…) tests.
Permalink
12.10.06
Posted in Java at 11:28 am by skoobi
Glen has a short tutorial on how to perform validation using Spring Valang (which is part of Spring Modules, which provide additional modules to integrate external projects with Spring, like OSCache, etc..) . While it is certainly better practice to choose XML validation instead of writing Validator classes manually, I personally prefer the @Annotations approach that is possible using Webwork / Struts 2.
Not only does it make people more productive by avoiding the need to edit 5 files at the same time (The Java class + the HTML/JSP/Freemarker template is all we should need to edit while creating a web application… Take a look at Tapestry 5 ), but it also shows the validation code at the same place at the code, and thus helps to maintain both.
However, I believe both approaches are not the way to go. We all use the validation features provided by our lovely MVC frameworks because it is handy, but when you think about it, validation should be part of the domain. The domain classes should be intelligent, they should have as much behavior as possible, and validation is one of the thing the domain should provide, in order to maintain integrity. For instance, if a domain layer has 2 User Interfaces (Web, and Swing, let’s say) interacting with it, the validation rules should only be implemented once, in the domain, not twice, because the integrity checks must be centralized.
But the frameworks are not quite there yet :
- Declarative (using annotations, for instance) is built into MVC frameworks and as such, are only tightly integrated to the view, not the domain. So, it requires more efforts to do validation on the domain. (Think of it as Spring MVC or Webwork validation, that automatically returns to the form and repopulates the data in case of an error VS throwing an exception that you have to handle manually)
- Validation defines constraints, and as such, is best expressed declaratively. However, if one wants to check constraints in the domain, it is necessary to either programmatically do it, or use AOP (maybe coupled with Annotations) to do so. However, it is still unclear whether AOP is a good thing to implement domain features. Lots of people tend to think of AOP as a way to implement cross-cutting TECHNICAL concerns, such as security, cache, or transaction demarcation.
Has anyone ever thought about that issue ? Have you implemented (programmatic) domain validation (maybe using Hibernate Validator, which is limited to persisted classes ?) on a real-life project ? What do you think about it ?
Permalink
12.09.06
Posted in Java at 3:02 pm by skoobi
Jurgen - whom I totally agree with - has written a very nice post about Procedural-Object programmers.
Most people tend to forget that Designing/Coding a piece of software is not about getting things to work, but more importantly, about getting things to work in an elegant way.
And the biggest problem is that it is really hard to define what “elegant” means. My personal opinion is that the Open Source world is full of very good practices that help drive the decisions. Sure, some software are crap, but looking at how Spring, Compass, Hibernate or other Java developers solve technical problems is in any case very informative.
Another problem is about designing the domain. For that part, I urge anybody to look at “Domain Driven Design Quickly” or Eric Evan’s Domain Driven Design book.
Permalink
12.06.06
Posted in Java at 9:20 am by skoobi
Java HotSwap support is being improved with each release. More information about it can be found in Jonas Bonér and Geert Bevin posts.
The goal of hot swapping is to allow the JVM to take new versions of the classes into considerations without reloading the JVM/Application.
Jonas believes it is a bad idea, but I think he refers to the ability of HotSwap to be used for AOP-like byte code instrumentation. Jonas seems to be heavily involved in AOP framework development, so I am not going to contradict any of his claims.
However, I DO believe that HotSwap can be used to improve the developer’s experience. Consider a web application that contains 100 Hibernate classes and takes 20-30 seconds to load. Most of the development time is spent loading and reloading the context, for each slight change in the Controller and View layers. Baiscally, if you want to add some stuff in a web page, you have to
1] Modify the action (Struts/Webwork Action, Spring MVC Controller, or Tapestry Page) to load the data from a database
2] Modify the view (.jsp/.jtl for Spring/Struts/Webwork, .html for Tapestry)
3] Deploy the application (30 seconds)
4] Test it. See that there is an error.
5] Correct the error, re-déploy the application (another 30 seconds)
and so on…
So, one of the solution is to use Jetty to deploy the application (for instance, using the Maven2 Jetty6 Plugin). This allows for hot-redeployment of JSP pages, but does not take the new classes changes into consideration. Jetty + Tapestry 5 is an attractive option for developers since it allows for hot deployment of both the HTML and Java code. This is awesome, except that I believe it should not be the MVC Framework’s job to do all the gory details of detecting new classes, re-loading the new ones, and so on. It is necessary to have a generic solution that will benefit all frameworks without specific support from them.
And this solution is called Java HotSwap. I am looking forward to having IDE support for that, that will allow to forget, once for all, this costly change-build-redeploy process.
Permalink
Posted in Java, Web Development at 3:04 am by skoobi
With globalization, Character Set problems are becoming more and more frequent, and are sometimes even a headache, as Mark Pilgrim and Scott Balmos highlight it in their respective posts entitled Determining the Character encoding of a feed and String encodings - another thorn in interop. Character sets are no more than a simple mapping between characters and numbers, and some encodings, such as Unicode UTF-8 tackle the interoperability issue correctly.
So, the real solution to all these problems would be to leverage UTF-8 as the default encoding for every application. If communication is necessary with a legacy system that does not support UTF-8, then whatever ISOxxx encoding is acceptable in a small wrapper that translates the stream to a UTF-8 one. In order to accomplish this :
- Make sure the default locale on all your systems are UTF-8. Recent linux distributions like Ubuntu luckily default to that.
- When writing or reading anything to a stream, Java (and I believe other languages too) defaults to the default encoding on the system. Do NOT trust this value, and make sure to only use the Reader/Writer constructors (example: OutputStreamWriter provides a few constructors that take the Charset. Use these constructors at ANY COST, and possibly write Jalopy rules that prevent the use of the default ones).
From a more general point of view, it would be desirable to have UTF-8 everywhere : Domain Name System (which stil uses ASCII), SMTP (which reverts to ugly hacks to allow people to write non-ASCII characters), etc…
The internet is an international place, and as such, should not be ASCII-centric. This means that if the standardization organisms (IETF, ..) do not realize this, we are going to see more and more forking such as China’s reform to its DNS, which is obviously a bad thing for the community since it creates more interoperability issues.
Permalink
11.28.06
Posted in Uncategorized, Java at 7:17 am by skoobi
Dalibor Topic has been interviewed (post here) concerning the recent announcement of Sun to make Java GPL, its implication on the Kaffe project.
As far as I am concerned, I strongly believe that Open Sourcing Java will open the door to more innovation and wider adoption around/of this technology. When it comes to high-level languages, the only truly Free (Libre) option on the linux/*NIX desktop was to use Mono/C# (more and more GNOME applications are written in C#). Adding more competition by releasing Java Open source will most probably lead to better, easier to maintain applications.
Another important point about the GPL’ing of Java is that Java itself will benefit from the change. Look at GCJ, for instance, which tries to get rid of the JVM and directly compile java to machine Code. It is yet to prove whether this approach would actually make Java faster, but in any case, it would help to better integrate Java with the unix-way of doing things, instead of having Java on one side, and the whole OS on the other side. Few to no efforts have actually been done in order to mix high-level languages with the system. GCJ is currently struggling to implement both the language and classlib aspects of Java. Once the classlib will be released as Open Source software, GCJ developpers will be able to concentrate on the compiler itself, and on the integration of Java with C/C++ code, which will be an incentive for the people who don’t like JVMs to use Java (after all, Java will just be a simpler C++ that provides a decent library by default).
Permalink
11.27.06
Posted in Java, Web Development at 12:20 am by skoobi
DWR is an Open Source Java library that allows to write AJAX-enabled Web Sites. Since the “AJAX” term is used to to describe pretty much anything from rich Web User Interfaces to auto-completing combo boxes to asynchronous communication between the web client and the server, here is a more technical introduction that explains what DWR allows to do :
DWR is basically a Remote Method Invocation framework that allows to “export” server-side Java Objects to the javascript-enabled web client thanks to a transparent communication layer that dynamically (at runtime) generates the client stubs. So, in other terms, You have server side Java methods that you want to run from the client. DWR takes these classes/methods and provides you with a javascript file (generated on-the-fly) that provides javascript classes/methods that once called, will handle all the method calls, marshalling/unmarshalling, etc..
DWR does not provide any UI-abstraction layer. In order to create nifty graphics, you have to complement it with another framework like Dojo toolkit, or Script.aculo.us
Since the official documentation isn’t particularly clear on how to get DWR to work with Spring-managed beans and Java5 Annotations, here is a mini-HOWTO that completes it. (Anyone is free to use this HOWTO under any OSI-approved Open Source license). Nothing is easier to understand than a simple example, so we are going to create a Client Side Logger API that logs the events on the server-side thanks to Log4j. (A real-world example should use some abstraction layer like Commons-Logging , and should result in the creation of a backend to some of the popular Javascript logging frameworks, like Log4Javascript, instead of reinventing yet another logging API).
As a sidenote, DWR is part of the typical Bleeding Edge Web-Framework Stack that I wrote about in a previous post. Surely, not everybody uses this Stack, but it gives an idea of what the current trend in the Java world is. The current java world is full of innovation. Every 2 days, a new framework arrives on the scene, and beginners are more and more afraid of the overall complexity of the platform (if we can call this a platform, because it more looks like a set of unrelated tools that people struggle to use together, in opposition to Microsoft .Net’s stack that we can safely call a “solution” because of the tight integration between the components). Innovation is doublessly a very good thing, and nothing should prevent innovation from happening. However, I believe it is also very important to document the best practices and tools and try to gather the community around a limited set of paradigms and frameworks. It doesn’t make sense to have a different framework for each programmer in this world. And in my humble opinion, using such an RMI-like system for communicating between Java classes and Javascript is definitely one of the best and efficient (from the developers viewpoint) practices around.
Java class
The first step is to create the annotated Java5 class that will be exported to the Javascript client. All exported methods must be annotated thanks to the @RemoteMethod annotation, and the @Create annotation is used at the class level to tell DWR that the class is instantiated using the Spring Framework. The beanName parameter must reflect the name of the bean in Spring’s application context file.
@Create(creator = SpringCreator.class, creatorParams = { @Param(name = “beanName”, value = “clientSideLogger”) })
public class ClientSideLogger {
public static Logger logger = Logger.getLogger(ClientSideLogger.class);
/**
* @param arg0
* @see org.apache.log4j.Category#debug(java.lang.Object)
*/
@RemoteMethod
public void debug(String arg0) {
logger.debug(arg0);
}
/**
* @param arg0
* @see org.apache.log4j.Category#error(java.lang.Object)
*/
@RemoteMethod
public void error(String arg0) {
logger.error(arg0);
}
/**
* @param arg0
* @see org.apache.log4j.Category#fatal(java.lang.Object)
*/
@RemoteMethod
public void fatal(String arg0) {
logger.fatal(arg0);
}
/**
* @param arg0
* @see org.apache.log4j.Category#info(java.lang.Object)
*/
@RemoteMethod
public void info(String arg0) {
logger.info(arg0);
}
/**
* @param arg0
* @see org.apache.log4j.Category#warn(java.lang.Object)
*/
@RemoteMethod
public void warn(String arg0) {
logger.warn(arg0);
}
Spring Configuration
In order to instantiate the ClientSideLogger class with Spring, we can create the following dwr.xml file, that is going to create a “clientSideLogger” singleton :
<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=”http://www.springframework.org/schema/aop” xmlns:tx=”http://www.springframework.org/schema/tx”
xsi:schemaLocation=”http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd”>
<bean id=”clientSideLogger” class=”fr.cvf.vodoo.ihm.portal.dwr.ClientSideLogger” />
</beans>
Web.xml glue
The next step is to write the usual glue (setup the DWR/Spring servlet, etc…).
In your web.xml, you can add :
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:spring/dwr.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!– DWR servlet , that should list all annotated classes–>
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR Servlet</display-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>classes</param-name>
<param-value>
package.ClientSideLogger
</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>dwr-invoker</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>
Javascript Code
The final step is to use the logging using the automagically generated javascript API.
First, make sure the following javascript files are included :
<script type=’text/javascript’ xsrc=’/dwr/interface/ClientSideLogger.js’>
</script>
<script type=’text/javascript’ xsrc=’/dwr/engine.js’></script>
<script type=’text/javascript’ xsrc=’/dwr/util.js’></script>
And you can use the API :
ClientSideLogger.error(”error message”);
That’s all you have to do !
Permalink
11.18.06
Posted in Java at 6:20 am by skoobi
Most developers now agree they should avoid heavyweight frameworks like EJB2. Maintenance is a nightmare, and more importantly, developers don’t enjoy anything that deals with the generation of stubs and skels (The same applies to technologies like CORBA).
So, what is the recommended technology stack for developing web applications today ? It looks like nowaday’s buzz goes toward :
- Apache Maven2 for build-management, and managing profiles (development, integration, production) and its set of plugins which ease application development, like Jetty6 plugin, which avoids constantly redeploying wars to tomcat.
- A so-called “lightweight” JEE framework, like the famous Spring Framework, that everybody raaaves about.
- A Object Relational Mapping framework, like Hibernate, or any of the Java Persistence API implementations (Hibernate EntityManager, OpenEJB, or Oracle TopLink)
- An MVC framework, which is either Action/Request Based (The 2 most popular ones being Spring MVC and Webwork2/Struts2 ), or Component Based (The 2 most popular ones being Apache Tapestry and Java Server Faces )
- A security framework like Acegi to handle authentication and authorization.
- In addition, other secondary frameworks are often used, like DWR for transparent AJAX, or the client side Dojo Toolkit Javascript framework.
From a methodology viewpoint, the current hype is about :
- Test-Driven-Development, thanks to some Unit testing frameworks like JUnit+Easymock, and functional-testing framework like Canoo Webtest.
- Inversion Of Control : Each technical (technical or functional) component must be described by an interface, and the inversion of control container - usually Spring - takes care of instantiating the right objects to avoid the need to create hundreds of Factories and Singletons).
- Aspect-Oriented Development (AOP) : User code should not be polluted by cross cutting aspects such as Security, performance, Transaction Management, etc. AOP is what allows to factor out this kind of code into reusable aspects.
- Domain Driven Development (DDD), to design rich domain POJOs. Since designing rich domain objects implies that the objects will be smart and will need to access technical objects like DAOs, and directly accessing the implementations would lower the testability of the application, DDD often means using something similar to Spring’s @Configurable annotation in addition to Spring’s AspectJ integration, to magically dependency-inject domain objects (which cannot be managed by spring, since they can be instantiated everywhere)
From my experience, integrating all these frameworks doesn’t work out-of-the-box. It is often necessary to play with the miscellaneous versions of each framework, and it sometimes causes headaches. Classpath issues and human errors are also a great cause of trouble.
If the proliferation of frameworks continues (and I believe it will) , integrated stacks (like AppFuse, but backed by commercial support) will emerge as a de-facto need for kickstarting developments. How many developers out there actually use the whole IoC/AOP/DDD/TDD fuzz ? By looking at the amount of problems I get by using all these frameworks, I have the feeling that not so many people do ……
A simple example of that, is for instance, the use of Spring AOP declarative Annotation-based (@Transactional) transaction management. Nobody tells you that you cannot use @Transactional on a Spring MVC controller, or that you have to activate CGLib proxying to use @Transactional on Webwork Actions. Sure, once you’ve run into the problem and analyzed the cause, the reasons seem obvious, but I still believe that something needs to be fixed with the integration of all these frameworks. Everything works as expected in isolation, but once you start to deal with dozens of frameworks, problems arise more often, and their cause isn’t always obvious. The access to the right frameworks should be eased to improve the overall quality of applications in the software industry.
Permalink
02.07.06
Posted in Java at 8:39 am by skoobi
This particularly interesting post shows how good Spring is : 70% reduction of code after EJB to Spring migration..
I guess Erik is talking about EJB 2, but it’s still very interesting !
Permalink
« Previous entries ·