Archive for the ‘Java’ Category
Some people will argue that it’s not worthy comparing Tomcat and JBoss, because one of them is a superset of the other. In fact JBoss is bundled with a forked version of Tomcat. So JBoss is Tomcat plus:
* JMS messaging provider
* Web Services engine (JAX-WS and/or JAX-RS)
* Management capabilities like JMX and a scripted administration interface
* A powerful data grid solution (Infinispan)
* Advanced security, e.g. out-of-the-box integration with 3rd party directories
* A dynamic and powerful clustering engine
* Transaction management service
Still many decision makers have to choose between these two, so lets’ take a deeper look at them.
The JBoss AS is an application server based on Java. It is an open source server and is usable in any operating system supported by Java.
Apache Tomcat, or its more widely known name Tomcat, is a servlet container (meaning it is a Java class that operates under the strictures of the Java Servlet API – a protocol by which a Java class responds to an http request). This is an open source server, providing a ‘pure Java’ HTTP web server environment in which code written in Java is capable of running.
Tomcat is only a servlet engine and JBoss offers many more functionalities out of the box. Still JBoss is no longer a heavyweight monolithic container, but a modular application server featuring true classloading isolation, modules loaded on demand, domain management and exceptionally lightweight container. It has a pluggable architecture and if required, you can unplug features from JBoss to make it essentially a Tomcat servlet container.
At the same time the plus going in favour of Tomcat is that it is fairly lightweight, and it means less memory requirement and a faster response. At the same time if you need certain JEE features beyond the Servlet API, you can easily enhance Tomcat. For example, if you need JPA features you can include Hibernate or OpenEJB and JPA works nearly out of the box.
Tomcat is hassle free and might be the right choice when you are not using much of Java features. It is a very good fit if it comes to web centric, user facing applications.
In case backend integration comes into play, a JEE application server should be considered. Last but not least, migrating a WAR developed for Tomcat to JBoss should be a 1 day exercise.
Some people still argue that instead of using application servers, one can still deliver a full stack application using Tomcat + Spring adding the right frameworks and writing the Spring integration layer with these frameworks. That’s for sure true. Still the logical question is what price you will have to pay for that. The JBoss project can be focused around average – to junior developers. Mastering the same complex stack of technologies with Tomcat and Spring requires skilled and well paid developers.
To make it short, Tomcat is merely an HTTP server and Java servlet container. JBoss is a full-blown JEE application servers, including an EJB container and all the other features of that stack. On the other hand, Tomcat has a lighter memory footprint (~60-70 MB), while JBoss weigh in at hundreds of megs. Tomcat is very popular for simple web applications, or applications using frameworks such as Spring that do not require a full JEE server. Administration of a Tomcat server is arguably easier, as there are fewer moving parts.
However, for applications that do require a full JEE stack (or at least more pieces that could easily be bolted-on to Tomcat) JBoss is one of the most popular open source offerings. JBoss has a larger and deeper user community, and a more mature codebase.
So, we should not really care anymore about which is better, but focus on the application requirements. However, you can still use the best of these two worlds in your enterprise applications.
It would be great if your could share your opinions on this topic Thanks in advance for your comments!
Aliona Kavalevich – Business Development Manager (LI page)
Altabel Group – Professional Software Development
Scala is a statically typed and multi-paradigm programming language that runs on Java virtual machine and provides Java like syntax with a few improvements.
Being a multi-paradigm programming language, Scala allows for mixing multiple programming styles such as object oriented, imperative and functional programming. Whether it’s good or not, it is not a question that could be answered with a yes or no. Supporters would say that programmers can choose from a variety of styles and stick to the best depending on their needs. The others would argue that putting together some features found in many other programming languages can’t work well, mostly by increasing complexity and making a programming language obscure.
Scala code compiles to a byte code and runs on Java virtual machine, thus it is compatible with other Java applications. If most of your code and libraries are from Java world, this can be nothing but a good thing. At the same time some additional complexity in Scala is dictated by assuring compatibility with Java.
For some developers the Scala code is obscure, for others could be a nice and neat form of solving some specific problems.
One more positive aspect of Scala is its conciseness. We all know how Java verbose is and how many boiler code developers write everyday including constructors, getters, variable initialisation (type and generics), semicolons and many others.
Now let’s see some other aspects of working with Scala:
At first sight the performance in Scala is very good, comparable to Java. Scala code compiles to the same byte code as Java does and runs on the same Java virtual machine. Still how fast Scala code is may vary from case to case and usually it’s up to the way how the code is written. The awareness of how to write a high performance Scala code is especially important for Java developers who are not very experienced in both Scala and functional programming.
There are not too many development tools created specifically to serve Scala, but fortunately, thanks to compatibility with Java it doesn’t look so bad. One family of tools hardly usable in Scala are those, which do some sort of code analysis, for instance code coverage and static code analysis. Static code analysis tools are even less usable.
The two worth to mention native Scala extensions are Lift web framework and Akka actors platform.
The majority of libraries and frameworks from a Java world, should be possible to use quite smoothly, which among other things, is thanks to implicit conversions in Scala.
Interoperability between Scala and other programming languages, including Java/C/C++, is very good, mostly because of running on Java virtual machine. What Java may talk to, Scala can do as well. Taking into account support for implicit conversions described above, I would state that Scala is one of the leaders of interoperability among all programming languages.
Developers are provided with all they need to test Scala applications efficiently. To follow a Test Driven Development methodology, they can use popular in Java world Junit tool. If someone is more keen on Behaviour Driven Development then ScalaTest is a way to go.
Monitoring and maintenance
One of the main monitoring tools to analyze production Scala applications is JMX (Java Management Extensions). This tool does its job well when we want to analyse some predefined statistics, but sometimes we need to investigate some aspects of a production application while it’s running and JMX can’t provide all required data. To deal with such scenarios, Java provides Java Virtual Machine Tool Interface (JVM TI) that allows for inspecting running Java applications but it can be used for Scala too.
Scala community, including forum, mailing list and blogs, is not the biggest in the world, but it’s very energetic. Most people who are part of a Scala community are very passionate developers, which are always happy to help others to solve their problems. Books are also great: Programming in Scala book by Marting Oderski, Lex Spoon and Bill Venners.
No one will argue that it is far behind other programming languages such as Java or C/C++. Still while looking for Scala developers we could search for Java developers with Scala interests as well. The learning curve is not massive as Scala follows Java syntax. In such case, at least on experienced Scala developer would help the team adopting new programming language.
Have you moved from Java to Scala? How do you find this language?
Thanks for sharing your opinion!
Aliona Kavalevich – Business Development Manager (LI page)
Altabel Group – Professional Software Development
Let`s start from the brief history of the two.
- Sending HTML page data to server using AJAX;
- Animating HTML element;
- Validating the HTML form;
- Storing user information that may help for Web Analytic, Ad tracking etc.
Mostly jQuery focuses on designers and inexperienced developers, still it could be of interest to experienced programmers as well. Here I will try to enumerate the reasons why:
1) Element’s selecting. Every jQuery operation starts from selecting one or more nodes from the DOM. jQuery’s selection syntax is an interesting hybrid of CSS 1, 2, bits of CSS 3, some XPath and a few custom extensions as well.
3) The $ function. You could say it is not true that that jQuery introduces only one object in the global namespace as there is also a $: the $ symbol is also set up as a shortcut for jQuery. This makes enough gently: if you want to back your former function $ (for example, if you have a piece of code based on Prototype), you can call jQuery.noConflict (), to return to his old the $. At the beginning you could considere the widespread using $ in jQuery is no more than a clever trick. But for some reason thinking of it in terms of the jQuery symbol makes everything seem a lot more sensible
5) Manipulating with DOM. jQuery offers a few smart ways of making large scale manipulations to the DOM. The first is quite surprising: the jQuery function can take a snippet of HTML which it will turn in to a DOM element.
6) The returned beast. Object, which is returned by the selectors jQuery, could be quite interesting. It represents a set of DOM-elements and behaves a bit like an array—it has a length property, items can be accessed by index and (most importantly) Firebug treats it as an array when displaying it in the interactive console. This is a clever illusion; the collection is actually a jQuery object, incorporating a large number of methods which can be used to query, modify and extend the collection of selected elements.
There are three principle categories of jQuery methods: those that manipulate all of the matched elements, those that return a value from the first matched object, and those that modify the selection itself. If you have Firebug you can try these out interactively: use this Insert jQuery bookmarklet first to load the jQuery library in to any page, then paste the code examples in to the Firebug console. I would like to note a convenient symmetry of these methods: they are used for display attributes (taking 2 arguments passed to or from a number of properties of the object), and to read the values of these attributes (if only one argument). This symmetry is used throughout jQuery, which greatly facilitates the storage API.
8) jQuery and Ajax. jQuery has the best API for working with Ajax. The most simple form of an Ajax call looks like jQuery(‘div#intro’).load(‘/some/fragment.html’). This performs a GET request against /some/fragment.html and populates div#intro with the returned HTML fragment. It’s a neat shortcut, but what if you want to do something more advanced like display an Ajax loading indicator? jQuery exposes custom events (ajaxStart, ajaxComplete, ajaxError and more) for you to hook in this kind of code.
9) Extensions. Considering the whole set of features as standard, it is worth noting that uzhaty jQuery version is only 20 KB, and even less if you use archive (. Gz). Additional functionality that extends beyond this delivery can be arranged with the help of extensions that can (and do) to add new methods to an existing jQuery. If you want, you can do something like this: jQuery (‘p’). bounceAroundTheScreenAndTurnGreen(); The extension mechanism in jQuery provides documented methods for adding them to the system. Simplicity and ease of use have attracted a large community of authors such extensions, the extensions directory has more than a hundred examples. Another nice feature is the ability to add your own selectors as well as their own methods. MoreSelectors expansion adds methods like div: color (red), which, for example, selects all div with red text.
10) Several words about leaky abstractions. When studying jQuery with more respect, you could struggle with one philosophical blocker. In certain cases, jQuery uses a truly unique methods to achieve a particular function: some parts (such as source code selectors) of this library look scary. If you do so , it requires an understanding of how the library works. To understand this, you need to know some basic concepts, the differences between browsers and a set of methods, which the library uses to get around them. No library can protect you 100% against weird browser behaviour, but as long as you have a grounding in the underlying theory you should be able to figure out if a problem stems from your own code, your library or the underlying implementation.
Elvira Golyak – Business Development Manager (LI page)
Elvira.Golyak@altabel.com | Skype ID: elviragolyak
Altabel Group – Professional Software Development
Nowadays there are dozens of Java web frameworks. Many of them serve the same purpose and so I have tried to elaborate just on the most popular and typical in functions ones in my post The Best Java Web Framework.
Although I didn’t seek to cover all the frameworks and mentioned that in the post, there were advisory comments to consider Grails framework in my analysis. Having been given that much respect from the developers, this framework is definitely worth to be given a separate attention.
So please find below an overview of the Grails framework, its advantages and why this framework might be the best for some developers.
Grails is an open source Java framework for creating web applications. Grails is actually built off Groovy which gives the immediate benefit of being more productive. The Groovy syntax is much terser than Java, it’s much easier to do things in one line of Groovy code that would take you several in Java. At the same time Groovy has the capability to work with Java seamlessly, but that’s the different story.
The Grails framework attempts to bring some of the lessons from Ruby on Rails into the Java world such as DRY (Don’t Repeat Yourself) and Convention over Configuration:
- Don’t Repeat Yourself (DRY). Grails enables you to write DRY code and in itself is a good example of how to be DRY. If you have any existing Java code reusing it in Grails should be no problem.
- Convention over configuration. If you adhere to the conventions set out by Grails (which are very sensible btw) you can become productive very quickly.
Grails gets most of its magic from Groovy, a scripting language that is targeted to the JVM and features a mix of static and dynamic typing, and a Java like syntax. Groovy scripts are compiled to Java classes and can import regular Java classes (and vice-versa), so you can leverage your existing libraries.
Grails feels a lot like a Rails framework. If you want experience the power of Rails but don’t feel like learning Ruby then try Grails. On the other hand, if you have spent any time with Rails, you will find Grails simple to learn (especially with a Java background).
GORM (Grails Object Relational Mapping) is used in Grails to map domain objects to their corresponding database table. GORM is written in Groovy, but under the hood, it’s using Hibernate 3. GORM objects look and act very much like Rails’ ActiveRecord objects.There is no explicit mapping required, and table associations are simple method calls inside the domain object (belongsTo(), hasMany(), etc).
Another strong point is the choice. The Java community tends to have an overwhelming number of frameworks, application servers, views (JSP, Velocity, Tag Libraries, etc) and libraries to choose from. While there are pros and cons to having so many options, the bottom line is that you get choice with Grails. Here are a few of them:
- Grails projects are wrapped up as ordinary WAR files, allowing you to deploy them into any J2EE compliant web server.
- Grails uses Hibernate 3 for persistence, but will also support JPA compliant technologies such as EJB3.
- Grails supports both GSP (Groovy Server Pages) and JSP as view technologies.
Community: Grails is targeted at Java developers (a very large community indeed). At the same time it is worth of admiring that the Grails developers weren’t afraid to acknowledge that another community/technology has done something really well.
To sum up here are the main advantages of this framework:
1. Grails is built on several popular frameworks, e.g. SiteMesh, Hibernate,Spring.
2. Java programmers will have a flat learn curve, especially for those familiar with Hibernate and Spring.
3. Grails is maintained by SpringSource.com, that means the flexibility and scalability is not just good, it’s great!
4. Grails can be deployed on many popular J2EE servers, e.g. JBoss, Tomcat, WebLogic etc.
Please share your experience of working with this framework. It would be great to hear both positive and negative comments on using it.
Java has been around for a while. Soon after its initial inception, Sun started to push the platform towards the web. Now many years later, there are dozens of web frameworks and every now and then the same question pops up: which Java web framework is best.
No framework is perfect, they all have their merits and they all have their breaking points. There is not a single web framework out there that will work for all requirements out there, still there could be found arguments why one framework is better than others and for what types of applications. So let’s have a look at most viable Java web frameworks:
Servlets and JSPs
Some developers say that JSP technology is seriously outdated, while others see it from a little other point of view. The fact of the matter is that Servlets and JSPs do nothing for you – you do everything including mapping request parameters to objects and validating them.
Even with a big variety of frameworks out there, there is still a place for Servlets & JSPs. Smaller web applications are still quickly and cleanly built using them and you don’t need any external dependencies either. The only side note is that you do it properly, which means using Servlets to invoke business logic, using JSPs to generate the view and having JSPs contain no Java code, only JSTL tags and if you want custom tags.
Pros: good for a few pages/functions to implement
Some hate it, some love it. The main reason most people hate it is its steep learning curve and the fact that people use it for all the wrong purposes. Speaking of the right purpose, JSF is primarily aimed at being used to build web components for enterprise applications. It is excellent for creating complex user interfaces as the framework takes care of wiring UI components to backend classes with automated validation and transformations going on. Due to its stateful nature you even have an object representation of the web UI available to you server side.
JSF itself is only the base actually. It is designed to be extended, and many third parties do just that. On top of JSF you also have JBoss, Richfaces, Icefaces, Primefaces, Oracle ADF, Apache Tomahawk, JBoss Seam, Omnifaces, etc. They all share the fact that they extend core JSF with more functionality, which usually comes in the form of Ajax controlled “rich internet components”. Jboss Seam is unique in that list as it does not actually aim to extend, but “seamlessly wire together” many frameworks and technologies to the enterprise platform.
Pros: Good for medium to complex enteprise webapps where full control over the front end is not a requirement. If the application is built and designed around a solid backend, JSF 2.1 is your friend.
Cons: Not an easy material. JSF is hard, and there isn’t rich online documentation. If your application aims around a rich and dynamic web 2.0 front end, JSF is not your friend.
Spring framework is not quite a ‘web framework’, but it is unique. IT shares JBoss Seam’s aim in wiring together many different technologies, both frontend and backend. You can use it as an alternative to Java Enterprise Edition technology, but you are just as free to wire Spring and JEE technologies into the same application.
So what does Spring offer itself? A bunch! It has a bean autowiring system to replace (or extend) the dependency injection model as it exists in the JEE specification. It also has an incredibly strong security model. Additionally instead of manually constructing objects, you “inject” them from a Spring managed context. Next Spring has a strong emphasis on the Model View Controller pattern. Spring provides default controller types for example, but you can also implement your own. As for the model layer the framework can setup JDBC, Hibernate, JPA, etc. for you and it can even manage the sessions and transactions. And finally it offers a built in web front end framework with easy to use annotations. I guess there is much more to add to this.
Pros: Excellent for building and maintaining large enterprise applications that also target other legacy systems and technologies. Spring is so flexible you’ll have the least trouble adapting it to whatever you already have floating around. Also there is a huge community around Spring.
Cons: Clunky due to its hugeness. There is also a big amount of legacy that the framework has to drag around.
Struts 2 is actually quite a clean and neat framework. If all you want to do is create simple web applications, “web 2.0″ or otherwise, then it isn’t a bad idea at all to consider Struts 2. But it has limitations. The security model is weak. In this world of web heightened security demands, the framework does nothing to assist you or to help you prevent doing it wrong.
Pros: Good for web applications that do not have high security demands but will be a mix of complex forms and dynamic frontend pages. Low learning curve.
Cons: Weak security
Wicket is also friendly to the developer. It integrates nicely into IDEs and even has built in support for hot-deployment making it far easier to change and debug your applications. Also boring and cumbersome features like making your application multilingual is made incredibly easy.
Pros: Wicket can handle most webapp needs including those that are oriented on the back-end and those that are oriented on the front-end.
Cons: Weak documentation (including the books); the alternative API design.
GWT offers incredibly powerful browser user interface capabilities; using it you can create the coolest web front ends with relatively little work. Google creates most of its own online web services using GWT.
On top of GWT itself Google also provides you a wide range of tools, for example a rich set of plugins for Eclipse. This makes it a complete package that is completely carried by Google itself. This keeps it all tightly integrated and documented, which is a big plus for a web framework.
Pros: Good to create highly complex and feature rich web user interfaces
Cons: The framework is different from any other framework out there. When you want to use it you start from scratch, so it may make it hard to adopt it for a new project.
This framework is relatively young. It lays down the rules, brings the conventions and provides you the foundation to allow you to quickly and painlessly develop web applications, without boilerplate, dependency conflicts or layer upon layer of configuration.
This framework can utilize the benefits of the Scala language (but it is also built for the Java language). The same is true for Play 2.0 which is out right now, and more so. This is mostly because the framework is modeled almost entirely after Ruby on Rails 3 including the available tooling.
Pros: stripping away the boring part of Java web development; being completely stateless and Rest-enabled; providing perfect hot-deployment without need for JRebel or JPA entities; integrates with many popular and important web technologies; manages dependencies for you without needing to learn the complexities of Maven; consolidates web dev into a neat package; incredibly easy ORM model based on Hibernate and JPA 2.0, with an additional layer that takes away the cumbersomeness.
Cons: The programming model is quite counter-intuitive; navigation is based on throwing exceptions. deploying is a bit of a mess using Play as you don’t deploy classes, you deploy the source files. The (alternative) way you manage a Play project makes it difficult to integrate it in for example a JEE application in a way that is easy to maintain.
For sure there are many, many more frameworks to be discussed, but most of them serve the same purpose. Could you pass out your personal recommendation what frameworks is better to use and for what types of application?
Thanks a lot in advance for sharing your advice!