Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

and many more ....

Featured FREE Whitepapers

What's New Here?


Google Guava Cache with regular expression patterns

Quite recently I’ve seen a nice presentation about Google Guava and we came to the conclusion in our project that it could be really interesting to use the its Cache functionallity. Let us take a look at the regexp Pattern class and its compile function. Quite often in the code we can see that each time a regular expression is being used a programmer is repeatidly calling the aforementioned Pattern.compile() function with the same argument thus compiling the same regular expression over and over again. What could be done however is to cache the result of such compilations – let us take a look at the RegexpUtils utility class: package pl.grzejszczak.marcin.guava.cache.utils;import; import; import;import java.util.concurrent.ExecutionException; import java.util.regex.Matcher; import java.util.regex.Pattern;import static java.lang.String.format;public final class RegexpUtils {private RegexpUtils() { throw new UnsupportedOperationException("RegexpUtils is a utility class - don't instantiate it!"); }private static final LoadingCache<String, Pattern> COMPILED_PATTERNS = CacheBuilder.newBuilder().build(new CacheLoader<String, Pattern>() { @Override public Pattern load(String regexp) throws Exception { return Pattern.compile(regexp); } });public static Pattern getPattern(String regexp) { try { return COMPILED_PATTERNS.get(regexp); } catch (ExecutionException e) { throw new RuntimeException(format("Error when getting a pattern [%s] from cache", regexp), e); } }public static boolean matches(String stringToCheck, String regexp) { return doGetMatcher(stringToCheck, regexp).matches(); }public static Matcher getMatcher(String stringToCheck, String regexp) { return doGetMatcher(stringToCheck, regexp); }private static Matcher doGetMatcher(String stringToCheck, String regexp) { Pattern pattern = getPattern(regexp); return pattern.matcher(stringToCheck); }} As you can see the Guava’s LoadingCache with the CacheBuilder is being used to populate a cache with a new compiled pattern if one is not found. Due to caching the compiled pattern if a compilation has already taken place it will not be repeated ever again (in our case since we dno’t have any expiry set). Now a simple test package pl.grzejszczak.marcin.guava.cache;import; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import pl.grzejszczak.marcin.guava.cache.utils.RegexpUtils;import java.util.regex.Pattern;import static java.lang.String.format;public class GuavaCache { private static final Logger LOGGER = LoggerFactory.getLogger(GuavaCache.class); public static final String STRING_TO_MATCH = "something";public static void main(String[] args) { runTestForManualCompilationAndOneUsingCache(1); runTestForManualCompilationAndOneUsingCache(10); runTestForManualCompilationAndOneUsingCache(100); runTestForManualCompilationAndOneUsingCache(1000); runTestForManualCompilationAndOneUsingCache(10000); runTestForManualCompilationAndOneUsingCache(100000); runTestForManualCompilationAndOneUsingCache(1000000); }private static void runTestForManualCompilationAndOneUsingCache(int firstNoOfRepetitions) { repeatManualCompilation(firstNoOfRepetitions); repeatCompilationWithCache(firstNoOfRepetitions); }private static void repeatManualCompilation(int noOfRepetitions) { Stopwatch stopwatch = new Stopwatch().start(); compileAndMatchPatternManually(noOfRepetitions); LOGGER.debug(format("Time needed to compile and check regexp expression [%d] ms, no of iterations [%d]", stopwatch.elapsedMillis(), noOfRepetitions)); }private static void repeatCompilationWithCache(int noOfRepetitions) { Stopwatch stopwatch = new Stopwatch().start(); compileAndMatchPatternUsingCache(noOfRepetitions); LOGGER.debug(format("Time needed to compile and check regexp expression using Cache [%d] ms, no of iterations [%d]", stopwatch.elapsedMillis(), noOfRepetitions)); }private static void compileAndMatchPatternManually(int limit) { for (int i = 0; i < limit; i++) { Pattern.compile("something").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something1").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something2").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something3").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something4").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something5").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something6").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something7").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something8").matcher(STRING_TO_MATCH).matches(); Pattern.compile("something9").matcher(STRING_TO_MATCH).matches(); } }private static void compileAndMatchPatternUsingCache(int limit) { for (int i = 0; i < limit; i++) { RegexpUtils.matches(STRING_TO_MATCH, "something"); RegexpUtils.matches(STRING_TO_MATCH, "something1"); RegexpUtils.matches(STRING_TO_MATCH, "something2"); RegexpUtils.matches(STRING_TO_MATCH, "something3"); RegexpUtils.matches(STRING_TO_MATCH, "something4"); RegexpUtils.matches(STRING_TO_MATCH, "something5"); RegexpUtils.matches(STRING_TO_MATCH, "something6"); RegexpUtils.matches(STRING_TO_MATCH, "something7"); RegexpUtils.matches(STRING_TO_MATCH, "something8"); RegexpUtils.matches(STRING_TO_MATCH, "something9"); } }} We are running a series of tests and checking the time of their execution. Note that the results of these tests are not precise due to the fact that the application is not being run in isolation so numerous conditions can affect the time of the execution. We are interested in showing some degree of the problem rather than showing the precise execution time. For a given number of iterations (1,10,100,1000,10000,100000,1000000) we are either compiling 10 regular expressions or using a Guava’s cache to retrieve the compiled Pattern and then we match them against a string to match. These are the logs: pl.grzejszczak.marcin.guava.cache.GuavaCache:34 Time needed to compile and check regexp expression [1] ms, no of iterations [1] pl.grzejszczak.marcin.guava.cache.GuavaCache:40 Time needed to compile and check regexp expression using Cache [35] ms, no of iterations [1] pl.grzejszczak.marcin.guava.cache.GuavaCache:34 Time needed to compile and check regexp expression [1] ms, no of iterations [10] pl.grzejszczak.marcin.guava.cache.GuavaCache:40 Time needed to compile and check regexp expression using Cache [0] ms, no of iterations [10] pl.grzejszczak.marcin.guava.cache.GuavaCache:34 Time needed to compile and check regexp expression [8] ms, no of iterations [100] pl.grzejszczak.marcin.guava.cache.GuavaCache:40 Time needed to compile and check regexp expression using Cache [3] ms, no of iterations [100] pl.grzejszczak.marcin.guava.cache.GuavaCache:34 Time needed to compile and check regexp expression [10] ms, no of iterations [1000] pl.grzejszczak.marcin.guava.cache.GuavaCache:40 Time needed to compile and check regexp expression using Cache [10] ms, no of iterations [1000] pl.grzejszczak.marcin.guava.cache.GuavaCache:34 Time needed to compile and check regexp expression [83] ms, no of iterations [10000] pl.grzejszczak.marcin.guava.cache.GuavaCache:40 Time needed to compile and check regexp expression using Cache [33] ms, no of iterations [10000] pl.grzejszczak.marcin.guava.cache.GuavaCache:34 Time needed to compile and check regexp expression [800] ms, no of iterations [100000] pl.grzejszczak.marcin.guava.cache.GuavaCache:40 Time needed to compile and check regexp expression using Cache [279] ms, no of iterations [100000] pl.grzejszczak.marcin.guava.cache.GuavaCache:34 Time needed to compile and check regexp expression [7562] ms, no of iterations [1000000] pl.grzejszczak.marcin.guava.cache.GuavaCache:40 Time needed to compile and check regexp expression using Cache [3067] ms, no of iterations [1000000] You can find the sources over here under the Guava/Cache directory or go to the url   Reference: Google Guava Cache with regular expression patterns from our JCG partner Marcin Grzejszczak at the Blog for coding addicts blog. ...

Groovy & Grails Understanding – Part2

Grails Grails is a web framework based on Groovy and Java which can be deployed into existing Java web servers, e.g. Tomcat or Jetty. Its scaffolding capabilities let you create a new project within a few minutes. Grails is based on the “convention over configuration” idea which allows the application to auto-wires itself based on naming schemes (instead of using configuration files, XML files). The Grails framework allows instance development without requiring any configuration. Grails accomplish this by automatically providing the Tomcat web container and the HSQLDB database during development. Grails uses GORM (Grails   Object Relational Mapping) for the persistence of the domain model. GORM is based on Hibernate. You can test with the HSQLDB and run in production against another database simply by changing the configuration file (DataSource.groovy). Grails uses Java EE as the architectural basis and Spring for structuring the application via dependency injection. Grails is plug-in based and provides its own build system (Gant). The Grails homepage provides several pre-defined plugins which extend the Grails framework. Grails has been developed with a number of goals in mind:Provide a high-productivity web framework for the Java platform. Re-use proven Java technologies such as Hibernate and Spring under a simple, consistent interface Offer a consistent framework which reduces confusion and is easy to learn. Offer documentation for those parts of the framework which matter for its users. Provide what users expect in areas which are often complex and inconsistent:Powerful and consistent persistence framework. Powerful and easy to use view templates using GSP (Groovy Server Pages). Dynamic tag libraries to easily create web page components. Good Ajax support which is easy to extend and customize.Provide sample applications which demonstrate the power of the framework. Provide a complete development mode, including web server and automatic reload of resources.Architecture Grails is an open source web application framework which leverages on Groovy (Figure 2: Grails is build on top of Groovy). It was first developed in 2005 and the first “1.0” release was announced in 2008 .Grails builds on several well-established software frameworks, and combines their functionality via Groovy. These frameworks include Java Enterprise Edition (Java EE, JEE), spring, Hibernate and Quartz. Grails combines the speed of scripting languages with the stability and security of Java and is therefore ideally suited for enterprise use. The Grails Directory Structure The Grails project structure (shown in Figure 3 below) relies heavily on convention and establishes a sensible organizational structure for an application’s various artifacts.Environment Setting Need to follow below steps for Grails environment setupInstall JDK1.5 or higher from oracle Point the JAVA_HOME environment variable at your JDK installation. Download the latest release of Grails from Unzip Grails Create a GRAILS_HOME environment variable Add GRAILS_HOME/bin to the PATHDomain Classes Domain classes are the lifeblood of a Grails application. A corresponding database table is automatically created for each domain class. Controllers and views derive their names from the associated domain class. This is where validation rules are stored, one-to-many relationships are defined, and much more. Below command to create domain class: grails create-domain-class domain-class-name Notice that Grails creates both a domain class and a test class. We’ll put the test class to use later. For now, let’s focus on the domain class Scaffolding Controllers and Views Controllers and views round out the “Big Three” in Grails applications. The Model/View/Controller (MVC) pattern is undoubtedly familiar to most web developers. By enforcing a clean separation of concerns among these three elements, your efforts are paid back in terms of maximum flexibility and reuse. Grails supports both static and dynamic scaffolding. The First example will show how to work with the static scaffolding. And afterwards there will be a small example on how to use dynamic scaffolding Static Scaffolding To generate the scaffolds in Grails, the following command will need to be executed through the command-line inside the project directoryIn this example, the ‘Address’ domain class will be scaffolded. The Controller and Views will now be generated for the developer. The way the code is generated, is based on templates that can be changed. Next to the CRUD actions, Grails adds the “list” action. The “edit” and “save” functions work together with “update” and “create”.Create create.gsp Creates a new addressRead show.gsp Show one address (Based on ID)Update edit.gsp Retrieve one address (Based on ID) that needs to be changedDelete No view Delete one address (Based on ID)List list.gsp List all addressesEdit No view Save the updated addressSave No view Saves the newly created addressThe AddressController now looks like this. The functions are self-explanatory. Class AddressController { Def index = { redirect (action:list, param:param)} //delete , save and update actions only accept post requests def allowedMethods =[delete: ‘POST’ , save:’POST’ , update: ‘POST’] def list = {//…….} def show = {//…….} def delete = {//…….} def edit = {//…….} def update = {//…….} def create = {//…….} def save = {//…….} Dynamic Scaffolding Dynamic Scaffolding in Grails is really easy. This can be achieved by adding the following line inside the controller that needs to be scaffolded. def scaffold =true The CRUD actions and views will be automatically generated at runtime for the previously defined model Databases – GORM The Grails Object-Relational Mapping API allows us to stay squarely in an Object frame of mind – no getting bogged down in relational database-related SQL. GORM is a thin Groovy façade over Hibernate. While creating an application, Grails automatically creates a Data source class where configurations for different environments can be defined. This allows for an easy switch between the development, test and production stage of a project. GORM data source could be configured on grailsapp/conf/DataSource.groovy dataSource { pooled = true driverClassName = “org.hsqldb.jdbcDriver” username =”sa” password = “” } Hibernate { Cache.use_second_level_cache = true Cache.use_query_cache = “true” Cache.provider_class = ‘com.opensymphony.oscace.hibernate.OSCachePovider’ } Environment { Development { dataSource { // one of ‘create’, create-drop’ , ‘update’ dbCreate= “create-drop” urk = “jdbc:hsqldb:main:devDB” } } Production { dataSource { dbCreate = “update” url = “jdbc:hsqldb:file:prodDB;shutdown=true” } } } Controllers View and Controller will be generated based on the Model and will automatically implement CRUD actions. Here we will expose the default scaffolded Controller code so that and relationship between actions in the Controllers and the URL. It will also allow us to see the relationship between action and the corresponding Groovy Server Pages (GSPs). create-controller vs. generate-controller Controller will be generated using scaffolding not only it generate controller but also generate GSP view using def scaffold =true. Normally I’d have you type “grails create-controller User” at this point. Recall that the create-* commands create an empty, stubbed out class. Instead, type grails generate-all User. The generate-all command writes out a fully implemented controller and a corresponding set of GSP views. (You can also type generate-views to see just the GSPs, or generate-controller to create just the Controller.) Instead of the one-line Controller you are used to seeing, you’ll now see 100 lines of Groovy code URLs and Controllers Class UserController { Static allowedMethods = {save: “POST”, update : “POST” , delete: “POST”| def index = { redirect {action: “lisy” , params} } def list = { params.max = Math.mi(params.max ?‘max’) :10,100) def create = { def userInstance =new User () = paams return { userInstance : userInstance} def save = {//…….} def show = {//…….} def delete = {//…….} def edit = {//…….} def update = {//…….} } Consider the types of URLs we saw as we worked our way through the application: http://localhost:9090/application/user/show/2 Each component of the URL plays an important role in the Grails convention. And it’s by following that convention that we (thankfully) free ourselves from having to wire together our URLs, controllers, and views in external configuration filesThe first part of the URL is the application name, or Application Context Root. The next part of the URL is the controller name. Notice that the Controller part of UserController gets dropped off, and the first letter is changed to lowercase. After the controller name, you’ll see an optional action name. This name corresponds directly to the action in the Controller. If we try “http://localhost:9090/application/user” in our web browser, we will end up with an empty list of users. Since no action is specified, Grails routes the request to the index action. The index action, in turn, redirects the request to the list action, passing along the query string as well. The name:value structure used in the redirect method is used throughout Controllers. GSP Grails uses GSP for the presentation tier. The Groovy in Groovy Server Pages not only identifies the underlying technology, but also the language you can use if you want to write a quick scriptlet or two. Groovy Taglib and partial templates give you a more sophisticated way of sharing code and behavior across Web pages. GSPs are the foundation of Grails’ page-centric MVC world view. The page is the basic unit of measure. The List page offers links to the Show page. The Show page allows you to click through to the Edit page, and so on. Whether you’re a seasoned Struts developer or a recent Rails enthusiast, you’re already familiar with this type of Web life cycle. A sample GSP page (list.gsp) depicted below: <g:each in=”${userInstanceList}” Satus=”i” var=”userInstance”> <tr class=”${(i%2)==0?’odd’ : ‘event’}”> <td> <g:link action=”show” id=”${}”> ${fieldValue{bean:userInstance, field:’id’)} </g:link> </td> <td>${fieldValue(bean:userInstance, field:’login’)}</td> <td>${fieldValue(bean:userInstance, field:’password’)}</td><td>${fieldValue(bean:userInstance, field:’role’)}</td>Scopes in Grails There are four scopes in Grails: request, flash, session, and application. Each one has a different lifespanVariables placed in request scope last just long enough to be displayed in the response and then are discarded. Values in flash scope (commonly used for error messages in Grails) can survive a single redirect. Session scope is used for values that should stick around for multiple requests, but are limited to the current user. Values placed in application scope are “global”—they last for as long as Grails is running, and they are shared across all users.Services Grails Service uses to separate your business logic from the other layer or component. Services are named in the format SomeNameService.groovy and placed in the directory /grails-app/services/. Services can make use of dependency injection features, and you can easily call these services from within controllers. Class SearchableService { Booleab transactional =true def compass def compassGps def searchableMethodFactory def search (Object[] args){ searcgableMethodFactory.getMethod(“searcg”).invoke(*args) } Above depicts the SearchableService. SearchableService (stored in grailsapp/services) got added to the SearchableController automatically using single line def searchableService right after the class declaration of the Controller. This is the way Grails uses dependency injection, or “DI” for short. Unit Testing Controllers Plug-in Grails plugins are like JARs on steroids. They can include not only one or more JARs, but also GSPs, Controllers, TagLibs, Codecs, and more. In essence, they are mini Grails applications expressly meant to be merged with other Grails applications. Unit Testing GrailsUnitTestCase and GroovyTestCase both extend JUnit 3.x TestCase.MVC Unit Test case will extend GrailsUNitTest case and delegate the test case control to ControllerUnitTestCase and TagLibUnitTestCaseGrailsUnitTestCase and its offspring offer mock services that replicate the services available in integration tests, without incurring the overhead of running the real services. A GrailsUnitTestCase makes three convenience methods available: mockForConstraintsTests(), mockDomain(), and mockLogging(). Normally you would have to create an integration test to write assertions against this functionality. And you still can, if you’d like. But knowing that unit tests run much faster than integration tests, it’s nice to be able to mock this behavior out. Import grails.test.* Class UserTests extends GrailsUnitTestCase { Void testsimpleConstraints { Def user = new User ( login: “someone”, password: “xxx”, role :”admin”) assertFals user.validate() }} For example, suppose that you’d like to test the validation on the User class. Deployment We can easily generate a WAR file and deploy it to Tomcat, JBoss, GlassFish, or the application server of your choice. Command “grails clean” will clean and to make sure that there aren’t any lingering development-mode artifacts hanging around. After clean command execute grails war . You should end up with a genuine JEE WAR file, suitable for deploying to any Java application server Import grails.test.* Class UserTests extends GrailsUnitTestCase { Void testsimpleConstraints { Def user = new User ( login: “someone”, password: “xxx”, role :”admin”) assertFals user.validate() }} No additional server configuration is necessary to deploy your WAR – it includes the Groovy JAR, the Grails supporting JARs, and everything else that you added to the lib directory. Summary Grails’s main target is to develop web application quickly and rapidly in agile manner. Grails is based on Convention over configuration and DRY(Don’t Repeat yourself) and not only that we can re use existing java code in Grails that give power to build robust and stable web application in quickly and rapid manner. This paper explained the usage and best practices around the Groovy and Grails. Resources Groovy – Groovy – Grails Codehaus’s testing guide: IBM’s fndings:  Reference: Groovy & Grails Understanding – Part2 from our JCG partner Nitin Kumar at the Tech My Talk blog. ...

Advantages and Disadvantages of Cloud Computing – Cloud computing pros and cons

Introduction Cloud computing refers to the use of computing resources, those being hardware and/or software) that reside on a remote machine and are delivered to the end user as a service over a network, with the most prevalent example being the internet. By definition, a user entrusts his data to a remote service, on which has limited to no influence. When it first appeared as a term and a concept, a lot of critics dismissed it as being the latest tech fad. However, cloud computing managed to cut through the hype and truly shift the paradigm of how IT is done nowadays. The Cloud has achieved cutting costs for enterprises and helping users focus on their core business instead of being obstructed by IT issues. For this reason, it seems that it is here to stay for the immediate future. Categories of Cloud Computing There are mainly four models of cloud computing:Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS) Network as a Service (Naas)Let’s discuss those in more detail. Infrastructure as a Service (IaaS): This is the most basic cloud-service model, which provides the user with virtual infrastructure, for example servers and data storage space. Virtualization plays a major role in this mode, by allowing IaaS-cloud providers to supply resources on-demand extracting them from their large pools installed in data centers. Platform as a Service (PaaS): In this model, cloud providers deliver to the user development environment services where the user can develop and run in-house built applications. The services might include an operating system, a programming language execution environment, databases and web servers. Software as a Service (SaaS): In this model, the cloud provides the user with access to already developer applications that are running in the cloud. The access is achieved by cloud clients and the cloud users do not manage the infrastructure where the application resides, eliminating with this the way the need to install and run the application on the cloud user’s own computers. Network as a Service (Naas): The least common model, where the user is provided with network connectivity services, such as VPN and bandwidth on demand. Advantages of Cloud Computing Cloud computing offers numerous advantages both to end users and businesses of all sizes. The obvious huge advantage is that you no more have to support the infrastructure or have the knowledge necessary to develop and maintain the infrastructure, development environment or application, as were things up until recently. The burden has been lifted and someone else is taking care of all that. Business are now able to focus on their core business by outsourcing all the hassle of IT infrastructure. Let’s visit some of the most important advantages of cloud computing and discuss them in more detail. Those will include both a company’s and an end-user’s perspective. Cost Efficiency This is the biggest advantage of cloud computing, achieved by the elimination of the investment in stand-alone software or servers. By leveraging cloud’s capabilities, companies can save on licensing fees and at the same time eliminate overhead charges such as the cost of data storage, software updates, management etc. The cloud is in general available at much cheaper rates than traditional approaches and can significantly lower the overall IT expenses. At the same time, convenient and scalable charging models have emerged (such as one-time-payment and pay-as-you-go), making the cloud even more attractive. If you want to get more technical and analytical, cloud computing delivers a better cash flow by eliminating the capital expense (CAPEX) associated with developing and maintaining the server infrastructure. Convenience and continuous availability Public clouds offer services that are available wherever the end user might be located. This approach enables easy access to information and accommodates the needs of users in different time zones and geographic locations. As a side benefit, collaboration booms since it is now easier than ever to access, view and modify shared documents and files. Moreover, service uptime is in most cases guaranteed, providing in that way continuous availability of resources. The various cloud vendors typically use multiple servers for maximum redundancy. In case of system failure, alternative instances are automatically spawned on other machines. Backup and Recovery The process of backing up and recovering data is simplified since those now reside on the cloud and not on a physical device. The various cloud providers offer reliable and flexible backup/recovery solutions. In some cases, the cloud itself is used solely as a backup repository of the data located in local computers. Cloud is environmentally friendly The cloud is in general more efficient than the typical IT infrastructure and It takes fewer resources to compute, thus saving energy. For example, when servers are not used, the infrastructure normally scales down, freeing up resources and consuming less power. At any moment, only the resources that are truly needed are consumed by the system. Resiliency and Redundancy A cloud deployment is usually built on a robust architecture thus providing resiliency and redundancy to its users. The cloud offers automatic failover between hardware platforms out of the box, while disaster recovery services are also often included. Scalability and Performance Scalability is a built-in feature for cloud deployments. Cloud instances are deployed automatically only when needed and as a result, you pay only for the applications and data storage you need. Hand in hand, also comes elasticity, since clouds can be scaled to meet your changing IT system demands. Regarding performance, the systems utilize distributed architectures which offer excellent speed of computations. Again, it is the provider’s responsibility to ensure that your services run on cutting edge machinery. Instances can be added instantly for improved performance and customers have access to the total resources of the cloud’s core hardware via their dashboards. Quick deployment and ease of integration A cloud system can be up and running in a very short period, making quick deployment a key benefit. On the same aspect, the introduction of a new user in the system happens instantaneously, eliminating waiting periods. Furthermore, software integration occurs automatically and organically in cloud installations. A business is allowed to choose the services and applications that best suit their preferences, while there is minimum effort in customizing and integrating those applications. Increased Storage Capacity The cloud can accommodate and store much more data compared to a personal computer and in a way offers almost unlimited storage capacity. It eliminates worries about running out of storage space and at the same time It spares businesses the need to upgrade their computer hardware, further reducing the overall IT cost. Device Diversity and Location Independence Cloud computing services can be accessed via a plethora of electronic devices that are able to have access to the internet. These devices include not only the traditional PCs, but also smartphones, tablets etc. With the cloud, the “Bring your own device” (BYOD) policy can be easily adopted, permitting employees to bring personally owned mobile devices to their workplace. An end-user might decide not only which device to use, but also where to access the service from. There is no limitation of place and medium. We can access our applications and data anywhere in the world, making this method very attractive to people. Cloud computing is in that way especially appealing to international companies as it offers the flexibility for its employees to access company files wherever they are. Smaller learning curve Cloud applications usually entail smaller learning curves since people are quietly used to them. Users find it easier to adopt them and come up to speed much faster. Main examples of this are applications like GMail and Google Docs. Disadvantages of Cloud Computing As made clear from the above, cloud computing is a tool that offers enormous benefits to its adopters. However, being a tool, it also comes with its set of problems and inefficiencies. Let’s address the most significant ones. Security and privacy in the Cloud Security is the biggest concern when it comes to cloud computing. By leveraging a remote cloud based infrastructure, a company essentially gives away private data and information, things that might be sensitive and confidential. It is then up to the cloud service provider to manage, protect and retain them, thus the provider’s reliability is very critical. A company’s existence might be put in jeopardy, so all possible alternatives should be explored before a decision. On the same note, even end users might feel uncomfortable surrendering their data to a third party. Similarly, privacy in the cloud is another huge issue. Companies and users have to trust their cloud service vendors that they will protect their data from unauthorized users. The various stories of data loss and password leakage in the media does not help to reassure some of the most concerned users. Dependency and vendor lock-in One of the major disadvantages of cloud computing is the implicit dependency on the provider. This is what the industry calls “vendor lock-in” since it is difficult, and sometimes impossible, to migrate from a provider once you have rolled with him. If a user wishes to switch to some other provider, then it can be really painful and cumbersome to transfer huge data from the old provider to the new one. This is another reason why you should carefully and thoroughly contemplate all options when picking a vendor. Technical Difficulties and Downtime Certainly the smaller business will enjoy not having to deal with the daily technical issues and will prefer handing those to an established IT company, however you should keep in mind that all systems might face dysfunctions from time to time. Outage and downtime is possible even to the best cloud service providers, as the past has shown. Additionally, you should remember that the whole setup is dependent on internet access, thus any network or connectivity problems will render the setup useless. As a minor detail, also keep in mind that it might take several minutes for the cloud to detect a server fault and launch a new instance from an image snapshot. Limited control and flexibility Since the applications and services run on remote, third party virtual environments, companies and users have limited control over the function and execution of the hardware and software. Moreover, since remote software is being used, it usually lacks the features of an application running locally. Increased Vulnerability Related to the security and privacy mentioned before, note that cloud based solutions are exposed on the public internet and are thus a more vulnerable target for malicious users and hackers. Nothing on the Internet is completely secure and even the biggest players suffer from serious attacks and security breaches. Due to the interdependency of the system, If there is a compromise one one of the machines that data is stored, there might be a leakage of personal information to the world. Conclusion Despite its disadvantages and the fact that it is still in an infant age, cloud computing remains strong and has great potential for the future. Its user base grows constantly and more big players are attracted to it, offering better and more fine tuned services and solutions. We can only hope that the advantages will further grow and the disadvantages will be mitigated, since cloud computing seems to have made IT a little bit easier. Happy cloud computing! ...

Hamcrest Matchers, Guava Predicate and Builder design pattern

Often, while coding we have to deal with some POJO objects that have dozens of fields in them. Many times we initialize those classes through a constructor having dozens of arguments which is terrible in any possibly imaginable way. Apart from that the functions that use those constructors are hardly testable. Let’s take a closer look at using a Builder to change that situation, together with Hamcrest matchers and Guava Predicates to unit test it. Let’s start off with taking a look at the POJO class.  package pl.grzejszczak.marcin.junit.matchers.pojo;/** * Created with IntelliJ IDEA. * User: mgrzejszczak * Date: 03.01.13 * Time: 21:05 */ public class SomeBigPojo { private String stringField0; private Integer integerField0; private Boolean booleanField0; private String stringField1; private Integer integerField1; private Boolean booleanField1; private String stringField2; private Integer integerField2; private Boolean booleanField2; private String stringField3; private Integer integerField3; private Boolean booleanField3; private String stringField4; private Integer integerField4; private Boolean booleanField4; private String stringField5; private Integer integerField5; private Boolean booleanField5; private String stringField6; private Integer integerField6; private Boolean booleanField6; private String stringField7; private String stringField8; private String stringField9;public SomeBigPojo(String stringField0, Integer integerField0, Boolean booleanField0, String stringField1, Integer integerField1, Boolean booleanField1, String stringField2, Integer integerField2, Boolean booleanField2, String stringField3, Integer integerField3, Boolean booleanField3, String stringField4, Integer integerField4, Boolean booleanField4, String stringField5, Integer integerField5, Boolean booleanField5, String stringField6, Integer integerField6, Boolean booleanField6, String stringField7, String stringField8, String stringField9) { this.stringField0 = stringField0; this.integerField0 = integerField0; this.booleanField0 = booleanField0; this.stringField1 = stringField1; this.integerField1 = integerField1; this.booleanField1 = booleanField1; this.stringField2 = stringField2; this.integerField2 = integerField2; this.booleanField2 = booleanField2; this.stringField3 = stringField3; this.integerField3 = integerField3; this.booleanField3 = booleanField3; this.stringField4 = stringField4; this.integerField4 = integerField4; this.booleanField4 = booleanField4; this.stringField5 = stringField5; this.integerField5 = integerField5; this.booleanField5 = booleanField5; this.stringField6 = stringField6; this.integerField6 = integerField6; this.booleanField6 = booleanField6; this.stringField7 = stringField7; this.stringField8 = stringField8; this.stringField9 = stringField9; }public String getStringField0() { return stringField0; }public void setStringField0(String stringField0) { this.stringField0 = stringField0; }public Integer getIntegerField0() { return integerField0; }public void setIntegerField0(Integer integerField0) { this.integerField0 = integerField0; }public Boolean getBooleanField0() { return booleanField0; }public void setBooleanField0(Boolean booleanField0) { this.booleanField0 = booleanField0; }public String getStringField1() { return stringField1; }public void setStringField1(String stringField1) { this.stringField1 = stringField1; }public Integer getIntegerField1() { return integerField1; }public void setIntegerField1(Integer integerField1) { this.integerField1 = integerField1; }public Boolean getBooleanField1() { return booleanField1; }public void setBooleanField1(Boolean booleanField1) { this.booleanField1 = booleanField1; }public String getStringField2() { return stringField2; }public void setStringField2(String stringField2) { this.stringField2 = stringField2; }public Integer getIntegerField2() { return integerField2; }public void setIntegerField2(Integer integerField2) { this.integerField2 = integerField2; }public Boolean getBooleanField2() { return booleanField2; }public void setBooleanField2(Boolean booleanField2) { this.booleanField2 = booleanField2; }public String getStringField3() { return stringField3; }public void setStringField3(String stringField3) { this.stringField3 = stringField3; }public Integer getIntegerField3() { return integerField3; }public void setIntegerField3(Integer integerField3) { this.integerField3 = integerField3; }public Boolean getBooleanField3() { return booleanField3; }public void setBooleanField3(Boolean booleanField3) { this.booleanField3 = booleanField3; }public String getStringField4() { return stringField4; }public void setStringField4(String stringField4) { this.stringField4 = stringField4; }public Integer getIntegerField4() { return integerField4; }public void setIntegerField4(Integer integerField4) { this.integerField4 = integerField4; }public Boolean getBooleanField4() { return booleanField4; }public void setBooleanField4(Boolean booleanField4) { this.booleanField4 = booleanField4; }public String getStringField5() { return stringField5; }public void setStringField5(String stringField5) { this.stringField5 = stringField5; }public Integer getIntegerField5() { return integerField5; }public void setIntegerField5(Integer integerField5) { this.integerField5 = integerField5; }public Boolean getBooleanField5() { return booleanField5; }public void setBooleanField5(Boolean booleanField5) { this.booleanField5 = booleanField5; }public String getStringField6() { return stringField6; }public void setStringField6(String stringField6) { this.stringField6 = stringField6; }public Integer getIntegerField6() { return integerField6; }public void setIntegerField6(Integer integerField6) { this.integerField6 = integerField6; }public Boolean getBooleanField6() { return booleanField6; }public void setBooleanField6(Boolean booleanField6) { this.booleanField6 = booleanField6; }public String getStringField7() { return stringField7; }public void setStringField7(String stringField7) { this.stringField7 = stringField7; }public String getStringField8() { return stringField8; }public void setStringField8(String stringField8) { this.stringField8 = stringField8; }public String getStringField9() { return stringField9; }public void setStringField9(String stringField9) { this.stringField9 = stringField9; }@Override public String toString() { final StringBuilder sb = new StringBuilder(); sb.append("SomeBigPojo"); sb.append("{stringField0='").append(stringField0).append('\''); sb.append(", integerField0=").append(integerField0); sb.append(", booleanField0=").append(booleanField0); sb.append(", stringField1='").append(stringField1).append('\''); sb.append(", integerField1=").append(integerField1); sb.append(", booleanField1=").append(booleanField1); sb.append(", stringField2='").append(stringField2).append('\''); sb.append(", integerField2=").append(integerField2); sb.append(", booleanField2=").append(booleanField2); sb.append(", stringField3='").append(stringField3).append('\''); sb.append(", integerField3=").append(integerField3); sb.append(", booleanField3=").append(booleanField3); sb.append(", stringField4='").append(stringField4).append('\''); sb.append(", integerField4=").append(integerField4); sb.append(", booleanField4=").append(booleanField4); sb.append(", stringField5='").append(stringField5).append('\''); sb.append(", integerField5=").append(integerField5); sb.append(", booleanField5=").append(booleanField5); sb.append(", stringField6='").append(stringField6).append('\''); sb.append(", integerField6=").append(integerField6); sb.append(", booleanField6=").append(booleanField6); sb.append(", stringField7='").append(stringField7).append('\''); sb.append(", stringField8='").append(stringField8).append('\''); sb.append(", stringField9='").append(stringField9).append('\''); sb.append('}'); return sb.toString(); } } Now take a look at the builder class that was used in order to get rid of usage of the humongous constructor. What is more you can set whatever you want to without the need to enter nulls for the undesired fields. package pl.grzejszczak.marcin.junit.matchers.builder;import pl.grzejszczak.marcin.junit.matchers.pojo.SomeBigPojo;import static;/** * Created with IntelliJ IDEA. * User: mgrzejszczak * Date: 03.01.13 * Time: 21:08 */ public class SomeBigPojoBuilder { /** A field with some default value */ private String stringField0 = "defaultValueForString0"; /** A field with some default value */ private Integer integerField0 = 100; /** A field with some default value */ private Boolean booleanField0 = true; private String stringField1; private Integer integerField1; private Boolean booleanField1; private String stringField2; private Integer integerField2; private Boolean booleanField2; private String stringField3; private Integer integerField3; private Boolean booleanField3; private String stringField4; private Integer integerField4; private Boolean booleanField4; private String stringField5; private Integer integerField5; private Boolean booleanField5; private String stringField6; private Integer integerField6; private Boolean booleanField6; private String stringField7; private String stringField8; private String stringField9;public SomeBigPojoBuilder setStringField0(String stringField0) { this.stringField0 = stringField0; return this; }public SomeBigPojoBuilder setIntegerField0(Integer integerField0) { this.integerField0 = integerField0; return this; }public SomeBigPojoBuilder setBooleanField0(Boolean booleanField0) { this.booleanField0 = booleanField0; return this; }public SomeBigPojoBuilder setStringField1(String stringField1) { this.stringField1 = stringField1; return this; }public SomeBigPojoBuilder setIntegerField1(Integer integerField1) { this.integerField1 = integerField1; return this; }public SomeBigPojoBuilder setBooleanField1(Boolean booleanField1) { this.booleanField1 = booleanField1; return this; }public SomeBigPojoBuilder setStringField2(String stringField2) { this.stringField2 = stringField2; return this; }public SomeBigPojoBuilder setIntegerField2(Integer integerField2) { this.integerField2 = integerField2; return this; }public SomeBigPojoBuilder setBooleanField2(Boolean booleanField2) { this.booleanField2 = booleanField2; return this; }public SomeBigPojoBuilder setStringField3(String stringField3) { this.stringField3 = stringField3; return this; }public SomeBigPojoBuilder setIntegerField3(Integer integerField3) { this.integerField3 = integerField3; return this; }public SomeBigPojoBuilder setBooleanField3(Boolean booleanField3) { this.booleanField3 = booleanField3; return this; }public SomeBigPojoBuilder setStringField4(String stringField4) { this.stringField4 = stringField4; return this; }public SomeBigPojoBuilder setIntegerField4(Integer integerField4) { this.integerField4 = integerField4; return this; }public SomeBigPojoBuilder setBooleanField4(Boolean booleanField4) { this.booleanField4 = booleanField4; return this; }public SomeBigPojoBuilder setStringField5(String stringField5) { this.stringField5 = stringField5; return this; }public SomeBigPojoBuilder setIntegerField5(Integer integerField5) { this.integerField5 = integerField5; return this; }public SomeBigPojoBuilder setBooleanField5(Boolean booleanField5) { this.booleanField5 = booleanField5; return this; }public SomeBigPojoBuilder setStringField6(String stringField6) { this.stringField6 = stringField6; return this; }public SomeBigPojoBuilder setIntegerField6(Integer integerField6) { this.integerField6 = integerField6; return this; }public SomeBigPojoBuilder setBooleanField6(Boolean booleanField6) { this.booleanField6 = booleanField6; return this; }public SomeBigPojoBuilder setStringField7(String stringField7) { this.stringField7 = stringField7; return this; }public SomeBigPojoBuilder setStringField8(String stringField8) { this.stringField8 = stringField8; return this; }public SomeBigPojoBuilder setStringField9(String stringField9) { this.stringField9 = stringField9; return this; }/** * Some function checking the state of our POJO */ private void checkState(){ checkNotNull(stringField1, "StringField1 must not be null!"); }public SomeBigPojo createSomeBigPojoWithBuilder() { checkState(); return new SomeBigPojo(stringField0, integerField0, booleanField0, stringField1, integerField1, booleanField1, stringField2, integerField2, booleanField2, stringField3, integerField3, booleanField3, stringField4, integerField4, booleanField4, stringField5, integerField5, booleanField5, stringField6, integerField6, booleanField6, stringField7, stringField8, stringField9); } } Take a look at the function checkState that verifies whether the object is of a desired state. In this way we may disallow the creation of an object if some conditions where not fullfiled. For that case we are using the Guava’s Predicate – checkNotNull method. Note that the concept behind the Builder pattern is to delegate creation of an object to a Builder. In fact in the pure Builder design pattern implementation we would have to have a Director, some abstraction over a Builder and the concrete implementation of the Builder as such. In our case we have a simplification of that pattern – I used the refactoring option of IntelliJ. What can be done to make it look even better is to remove the constructor from the POJO and pass the values only by setters (that’s what in fact I did in one of my projects). Now let’s take a look at some usage examples: package pl.grzejszczak.marcin.junit.matchers.service;import org.slf4j.Logger; import org.slf4j.LoggerFactory; import pl.grzejszczak.marcin.junit.matchers.builder.SomeBigPojoBuilder; import pl.grzejszczak.marcin.junit.matchers.pojo.SomeBigPojo;import static java.lang.String.format;/** * Created with IntelliJ IDEA. * User: mgrzejszczak * Date: 03.01.13 * Time: 21:25 */ public class SomeServiceImpl implements SomeService { private static final Logger LOGGER = LoggerFactory.getLogger(SomeServiceImpl.class);/** Could be an abstraction of builders injected by a setter - possible to mock */ private SomeBigPojoBuilder someBigPojoBuilder;/** * Hard to unit test */ @Override public void someLogicForAPojoWithoutBuilder() { LOGGER.debug("SomeLogicForAPojoWithoutBuilder executed"); SomeBigPojo someBigPojo = new SomeBigPojo("string", 1, false, "other string", 123, true, "something else", 321, false, "yet another string", 111, true, "something", 2, false, "More", 3, true, "String", 12, false, "some", "value", "ofString"); // Any chance of knowing what is the value of stringField8 basing on the constructor? LOGGER.debug(format("StringField8 is equal [%s]%n", someBigPojo.getStringField8())); // Print the object LOGGER.debug(someBigPojo.toString()); }@Override public void someLogicForAPojoWithBuilder() { LOGGER.debug("SomeLogicForAPojoWithBuilder executed"); SomeBigPojo someBigPojo = someBigPojoBuilder .setStringField0("string") .setIntegerField0(1) .setBooleanField0(false) .setStringField1("other string") .setIntegerField1(123) .setBooleanField1(true) .setStringField2("something else") .setIntegerField2(321) .setBooleanField2(false) .setStringField3("yet another string") .setIntegerField3(111) .setBooleanField3(false) .setStringField4("something") .setIntegerField4(2) .setBooleanField4(false) .setStringField5("More") .setIntegerField5(3) .setBooleanField5(true) .setStringField6("String") .setIntegerField6(12) .setBooleanField6(false) .setStringField7("some") .setStringField8("value") .setStringField9("ofString") .createSomeBigPojoWithBuilder(); // Looking at the builder now I guess it's obvious what the value of StringField8 LOGGER.debug(format("StringField8 is equal [%s]%n", someBigPojo.getStringField8())); // Print the object LOGGER.debug(someBigPojo.toString()); }@Override public void someLogicForAPojoWithBuilderBadArgument() { LOGGER.debug("someLogicForAPojoWithBuilderBadArgument executed"); SomeBigPojo someBigPojo = someBigPojoBuilder .setStringField0("string") .setIntegerField0(1) .setBooleanField0(true) .setIntegerField1(123) .setBooleanField1(true) .setStringField2("something else") .setIntegerField2(321) .setBooleanField2(false) .setStringField3("yet another string") .setIntegerField3(111).setBooleanField3(false) .setStringField4("something") .setIntegerField4(2) .setBooleanField4(false) .setStringField5("More") .setIntegerField5(3) .setBooleanField5(true) .setStringField6("String") .setIntegerField6(12) .setBooleanField6(false) .setStringField7("some") .setStringField8("value") .setStringField9("ofString") .createSomeBigPojoWithBuilder(); // Print the object - will we even see an output LOGGER.debug(someBigPojo.toString()); }public void setSomeBigPojoBuilder(SomeBigPojoBuilder someBigPojoBuilder) { this.someBigPojoBuilder = someBigPojoBuilder; } } Notice how clear it is now to create an object and how easy is to define if a field has been set or not. Let’s move on to Hamcrest matchers that will help us in unit testing of our classes. I will not try to do the complete, 100% code coverage – the idea behind this post is to show how Hamcrest Matchers can become an addition to your unit tests. Often unit tests are quite unclear and look like this: package pl.grzejszczak.marcin.junit.matchers.builder;import org.junit.Before; import org.junit.Test; import pl.grzejszczak.marcin.junit.matchers.pojo.SomeBigPojo;import static junit.framework.Assert.assertTrue; import static org.apache.commons.lang.StringUtils.isNumeric; import static pl.grzejszczak.marcin.junit.matchers.pojo.SomePojoConstants.*;/** * Created with IntelliJ IDEA. * User: mgrzejszczak * Date: 03.01.13 * Time: 23:02 */ public class SomeBigPojoBuilderNoMatchersAndNoRefactoringTest {private SomeBigPojoBuilder objectUnderTest;@Before public void setUp() { objectUnderTest = new SomeBigPojoBuilder(); }@Test public void testCreateSomeBigPojoWithBuilder() throws Exception { SomeBigPojo someBigPojo = objectUnderTest .setBooleanField1(true) .setStringField0("1") .setStringField1("12") .setStringField2("123") .setStringField3("1234") .setStringField4("12345") .setStringField5("123456") .setStringField6("1234567") .setStringField7("12345678") .setStringField8("123456789") .setStringField9("1234567890") .createSomeBigPojoWithBuilder();isPojoProperlyBuilt(someBigPojo); }@Test(expected = AssertionError.class) public void testCreateSomeBigPojoWithBuilderWrongFields() throws Exception { SomeBigPojo someBigPojo = objectUnderTest .setStringField0("0") .setStringField1("Too long") .createSomeBigPojoWithBuilder();isPojoProperlyBuilt(someBigPojo); }private void isPojoProperlyBuilt(SomeBigPojo someBigPojo) { assertTrue(someBigPojo.getStringField0().length() == STRING_FIELD_0_LENGTH); assertTrue(isNumeric(someBigPojo.getStringField0()));assertTrue(someBigPojo.getStringField1().length() == STRING_FIELD_1_LENGTH); assertTrue(isNumeric(someBigPojo.getStringField0()));assertTrue(someBigPojo.getStringField2().length() == STRING_FIELD_2_LENGTH); assertTrue(isNumeric(someBigPojo.getStringField0()));assertTrue(someBigPojo.getStringField3().length() == STRING_FIELD_3_LENGTH); assertTrue(isNumeric(someBigPojo.getStringField0()));assertTrue(someBigPojo.getStringField4().length() == STRING_FIELD_4_LENGTH); assertTrue(isNumeric(someBigPojo.getStringField0()));assertTrue(someBigPojo.getStringField5().length() == STRING_FIELD_5_LENGTH);assertTrue(someBigPojo.getStringField6().length() == STRING_FIELD_6_LENGTH);assertTrue(someBigPojo.getStringField7().length() == STRING_FIELD_7_LENGTH);assertTrue(someBigPojo.getStringField8().length() == STRING_FIELD_8_LENGTH);assertTrue(someBigPojo.getStringField9().length() == STRING_FIELD_9_LENGTH);} } Simple refactoring can make them look nicer… package pl.grzejszczak.marcin.junit.matchers.builder;import org.junit.Before; import org.junit.Test; import pl.grzejszczak.marcin.junit.matchers.pojo.SomeBigPojo;import static junit.framework.Assert.assertNotNull; import static junit.framework.Assert.assertTrue; import static org.apache.commons.lang.StringUtils.isNumeric; import static pl.grzejszczak.marcin.junit.matchers.pojo.SomePojoConstants.*;/** * Created with IntelliJ IDEA. * User: mgrzejszczak * Date: 03.01.13 * Time: 23:02 */ public class SomeBigPojoBuilderNoMatchersTest {private SomeBigPojoBuilder objectUnderTest;@Before public void setUp() { objectUnderTest = new SomeBigPojoBuilder(); }@Test public void testCreateSomeBigPojoWithBuilder() throws Exception { SomeBigPojo someBigPojo = objectUnderTest .setBooleanField1(true) .setStringField0("1") .setStringField1("12") .setStringField2("123") .setStringField3("1234") .setStringField4("12345") .setStringField5("123456") .setStringField6("1234567") .setStringField7("12345678") .setStringField8("123456789") .setStringField9("1234567890") .createSomeBigPojoWithBuilder();isPojoProperlyBuilt(someBigPojo); }@Test(expected = AssertionError.class) public void testCreateSomeBigPojoWithBuilderWrongFields() throws Exception { SomeBigPojo someBigPojo = objectUnderTest .setStringField0("0") .setStringField1("too long") .createSomeBigPojoWithBuilder();isPojoProperlyBuilt(someBigPojo); }private void isPojoProperlyBuilt(SomeBigPojo someBigPojo) { isOfGivenLength(someBigPojo.getStringField0(), STRING_FIELD_0_LENGTH); isFieldOfNumericValue(someBigPojo.getStringField0());isOfGivenLength(someBigPojo.getStringField1(), STRING_FIELD_1_LENGTH); isFieldOfNumericValue(someBigPojo.getStringField0());isOfGivenLength(someBigPojo.getStringField2(), STRING_FIELD_2_LENGTH); isFieldOfNumericValue(someBigPojo.getStringField0());isOfGivenLength(someBigPojo.getStringField3(), STRING_FIELD_3_LENGTH); isFieldOfNumericValue(someBigPojo.getStringField0());isOfGivenLength(someBigPojo.getStringField4(), STRING_FIELD_4_LENGTH); isFieldOfNumericValue(someBigPojo.getStringField0());isOfGivenLength(someBigPojo.getStringField5(), STRING_FIELD_5_LENGTH);isOfGivenLength(someBigPojo.getStringField6(), STRING_FIELD_6_LENGTH);isOfGivenLength(someBigPojo.getStringField7(), STRING_FIELD_7_LENGTH);isOfGivenLength(someBigPojo.getStringField8(), STRING_FIELD_8_LENGTH);isOfGivenLength(someBigPojo.getStringField9(), STRING_FIELD_9_LENGTH);}private void isOfGivenLength(String pojo, final Integer expectedLength) { assertNotNull(pojo); assertTrue(expectedLength == pojo.length()); }private void isFieldOfNumericValue(String field) { assertTrue(isNumeric(field)); } } That looks nice, doesn’t it? And how about using Matchers instead of functions? SomeBigPojoBuilderTest.kava package pl.grzejszczak.marcin.junit.matchers.builder;import org.hamcrest.BaseMatcher; import org.hamcrest.Description; import org.hamcrest.Matcher; import org.junit.Before; import org.junit.Test; import pl.grzejszczak.marcin.junit.matchers.pojo.SomeBigPojo;import static java.lang.String.format; import static junit.framework.Assert.assertTrue; import static org.apache.commons.lang.StringUtils.isNumeric; import static org.junit.Assert.assertThat; import static pl.grzejszczak.marcin.junit.matchers.pojo.SomePojoConstants.*;/** * Created with IntelliJ IDEA. * User: mgrzejszczak * Date: 03.01.13 * Time: 23:02 */ public class SomeBigPojoBuilderTest {private SomeBigPojoBuilder objectUnderTest;@Before public void setUp(){ objectUnderTest = new SomeBigPojoBuilder(); }@Test public void testCreateSomeBigPojoWithBuilder() throws Exception { SomeBigPojo someBigPojo = objectUnderTest .setBooleanField1(true) .setStringField0("1") .setStringField1("12") .setStringField2("123") .setStringField3("1234") .setStringField4("12345") .setStringField5("123456") .setStringField6("1234567") .setStringField7("12345678") .setStringField8("123456789") .setStringField9("1234567890") .createSomeBigPojoWithBuilder();assertThat(someBigPojo, isPojoProperlyBuilt()); }@Test(expected = AssertionError.class) public void testCreateSomeBigPojoWithBuilderWrongFields() throws Exception { SomeBigPojo someBigPojo = objectUnderTest .setStringField0("0") .setStringField1("Too long") .createSomeBigPojoWithBuilder();assertThat(someBigPojo, isPojoProperlyBuilt()); }/** * Let us assume that there is a specific business case that we have to take into consideration regarding some particular field * * @return */ private static Matcher isPojoProperlyBuilt() {return new BaseMatcher() {@Override public boolean matches(Object o) { assertTrue(o instanceof SomeBigPojo); SomeBigPojo someBigPojo = (SomeBigPojo) o; assertThat(someBigPojo.getStringField0(), isOfGivenLength(STRING_FIELD_0_LENGTH)); assertThat(someBigPojo.getStringField0(), isFieldOfNumericValue());assertThat(someBigPojo.getStringField1(), isOfGivenLength(STRING_FIELD_1_LENGTH)); assertThat(someBigPojo.getStringField1(), isFieldOfNumericValue());assertThat(someBigPojo.getStringField2(), isOfGivenLength(STRING_FIELD_2_LENGTH)); assertThat(someBigPojo.getStringField2(), isFieldOfNumericValue());assertThat(someBigPojo.getStringField3(), isOfGivenLength(STRING_FIELD_3_LENGTH)); assertThat(someBigPojo.getStringField3(), isFieldOfNumericValue());assertThat(someBigPojo.getStringField4(), isOfGivenLength(STRING_FIELD_4_LENGTH)); assertThat(someBigPojo.getStringField4(), isFieldOfNumericValue());assertThat(someBigPojo.getStringField5(), isOfGivenLength(STRING_FIELD_5_LENGTH));assertThat(someBigPojo.getStringField6(), isOfGivenLength(STRING_FIELD_6_LENGTH));assertThat(someBigPojo.getStringField7(), isOfGivenLength(STRING_FIELD_7_LENGTH));assertThat(someBigPojo.getStringField8(), isOfGivenLength(STRING_FIELD_8_LENGTH));assertThat(someBigPojo.getStringField9(), isOfGivenLength(STRING_FIELD_9_LENGTH));return true; }@Override public void describeTo(Description description) { description.appendText("Lengths of fields are limited and the first 4 fields are numeric"); } }; }private static Matcher isOfGivenLength(final Integer expectedLength) {return new BaseMatcher() {public boolean matches(Object o) { assertTrue(o instanceof String); return expectedLength == String.valueOf(o).length(); }public void describeTo(Description description) { description.appendText(format("String's length should be equal to [%d]", expectedLength)); } }; }private static Matcher isFieldOfNumericValue() {return new BaseMatcher() {public boolean matches(Object o) { assertTrue(o instanceof String); return isNumeric(String.valueOf(o)); }public void describeTo(Description description) { description.appendText("The value of the field should be numeric"); } }; } } The following main method executes the functions of the Service: package pl.grzejszczak.marcin.junit.matchers;import pl.grzejszczak.marcin.junit.matchers.builder.SomeBigPojoBuilder; import pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl;/** * Created with IntelliJ IDEA. * User: mgrzejszczak * Date: 03.01.13 * Time: 22:38 */ public class MatcherMain { public static void main(String[] args){ SomeServiceImpl someService = new SomeServiceImpl();someService.setSomeBigPojoBuilder(new SomeBigPojoBuilder()); someService.someLogicForAPojoWithoutBuilder();someService.setSomeBigPojoBuilder(new SomeBigPojoBuilder()); someService.someLogicForAPojoWithBuilder();someService.setSomeBigPojoBuilder(new SomeBigPojoBuilder()); someService.someLogicForAPojoWithBuilderBadArgument(); } } And the logs are: pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl:27 SomeLogicForAPojoWithoutBuilder executed pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl:30 StringField8 is equal [value] pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl:32 SomeBigPojo{stringField0='string', integerField0=1, booleanField0=false, stringField1='other string', integerField1=123, booleanField1=true, stringField2='something else', integerField2=321, booleanField2=false, stringField3='yet another string', integerField3=111, booleanField3=true, stringField4='something', integerField4=2, booleanField4=false, stringField5='More', integerField5=3, booleanField5=true, stringField6='String', integerField6=12, booleanField6=false, stringField7='some', stringField8='value', stringField9='ofString'} pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl:37 SomeLogicForAPojoWithBuilder executed pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl:65 StringField8 is equal [value] pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl:67 SomeBigPojo{stringField0='string', integerField0=1, booleanField0=false, stringField1='other string', integerField1=123, booleanField1=true, stringField2='something else', integerField2=321, booleanField2=false, stringField3='yet another string', integerField3=111, booleanField3=false, stringField4='something', integerField4=2, booleanField4=false, stringField5='More', integerField5=3, booleanField5=true, stringField6='String', integerField6=12, booleanField6=false, stringField7='some', stringField8='value', stringField9='ofString'} pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl:72 someLogicForAPojoWithBuilderBadArgument executed Exception in thread "main" java.lang.NullPointerException: StringField1 must not be null! at at pl.grzejszczak.marcin.junit.matchers.builder.SomeBigPojoBuilder.checkState( at pl.grzejszczak.marcin.junit.matchers.builder.SomeBigPojoBuilder.createSomeBigPojoWithBuilder ( at pl.grzejszczak.marcin.junit.matchers.service.SomeServiceImpl.someLogicForAPojoWithBuilderBadArgument ( at pl.grzejszczak.marcin.junit.matchers.MatcherMain.main( at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( at sun.reflect.DelegatingMethodAccessorImpl.invoke( at java.lang.reflect.Method.invoke( at com.intellij.rt.execution.application.AppMain.main( In my opinion that looks really nice . And what is yours? Sources are available here at Too Much Codings code repository.   Reference: Hamcrest Matchers, Guava Predicate and Builder design pattern from our JCG partner Marcin Grzejszczak at the Blog for coding addicts blog. ...

Infamous Java bugs and pitfalls

In year 2000, I was in university and was on the verge of picking a language to build my career on. Java was not yet the mainstream but highly popular and on the spots. Applets were (not yet broken) fancy, shiny when compared to static html pages. Swing was not a bad choice to build desktop apps. J2EE was rising and getting attention. It has been 13 years since then and Java went mainstream although applets failed miserably, not really considered for desktop apps and J2EE was too complicated to even build simple stuff but still nothing stopped Java from being the most popular programming language. It was no surprise, Java is beatiful, type safe and easy to learn language. There were many very good implemantation details in Java such the garbage collector, strings   (finalized class), collections which offer great implemantations of merge and quicksort, built in hashcode methods and many more. However, still Java is far from being perfect and may introduce some unexpected behaviour. The abs bug: Well this is a very minor flaw but there is a probability that Math.abs() function may return negative value. Weird? actually simple, Java integers can get a value between -2,147,483,648 to 2,147,483,647 which clearly shows -2,147,483,648 can not be represented in positive. So is this a bug? Well the expected value is positive so yes definitely but in the end this is actually an overflow. So how to fix it? One way would be checking Integer.MIN_VALUE before using abs function or using bit operators to manipulate negative sign instead. Autoboxing the primitives pitfalls: Autoboxing makes it easy to work with primitive types and their object counterpart. However moving between them may introduce some unexpected behavior. For example Integer i1=6 can not be compared to Integer i2=6 with == operator where int i3=6 can be compared to those with ==. However using equals may not work as expected too. For example Long x=0L; returns true when x.equals(0L) but returns false when x.equals(0). Weird? Not really since x is long where 0 (without L) is int. So those are not even same object types. Also using primitive types with collections may result unexpected behavior. Finally Autoboxing may result problems in overloading. Lets say we have Integer i=6 and call method sum(i); and we have two sum methods like; sum(long val) and sum(Long val). Which one do you think will be called? Again reasonable but not expected to see at first look and may lead problems in your app. BigDecimal constructor bug: If you haven’t already check Java Puzzlers from Joshua Bloch. If you create two Big decimals using double constructor (x1=new BigDecimal(2.00) and x2=new BigDecimal (1.10)) and use subtract (x1.subtract(x2)) you will end up with 0.8999999999. The double constructor of BigDecimal doesn’t work as expected and string constructor needs to be used instead (new BigDecimal(“2.00″)). This might be a serious problem since BigDecimal is widely used for money calculations! System.out.println pitfall: println() is one of the first functions that is tought to cs students. It is easy and used often. Usually quite ok to use when you are trying some logic or debugging some values. However System.out is synchronized so acquires a lock when accessed. So using println can cause your app to run in synchronized context which actually means threads will be blocked when accessing println. Imagine a webserver and an app logging with println and you will end up with thread locks and each request waiting for other. So println is ok and useful but not for real apps and logging! Map bug: Again take a look at Java Puzzlers from Joshua Bloch, the fifth puzzle(size matters) introduces a strange behavior between an HashMap and an EnumMap where with same values, one map has a size of 2 where the other is 1. Several Map implementations such as IdentityHashMap, EnumMap may introduce this behavior. Is this a bug? Well certainly we expect same principles from map implementations but Bloch describes that as the spec was not clear at the time. Cpu Number bug: This may not be a huge problem unless you really rely on hardware. To get available processor count Java offers Runtime.getRuntime().availableProcessors() method which returns an int number as the number of the processors available. However you may end up getting unexpected numbers if you give a try. For example on my quad-core i7, I get 8. So this method does not return the number of hardware cpus nor the number of cores but the number of execution engines (virtual cores). In my case because quad-core i7s support hyper treading it actually acts like it has eight cores. So is this a bug? Definitely not since the hardware and the OS acts as if they have that number of physical cpus but still be careful counting if you rely on solid hardware. Generic arrays In Java arrays are created as follows, int[] arr=new int[5]; so if you have a generic type of T, you would expect to create a generic array this way: T[]=new T[5]; but simply you can’t. Java does not allow generic array creation and this is actually because generics are implemented in Java using Erasure. Generics are implemented purely in compiler level and actually only one class file is generated for each class. So to create the array we need an ugly cast as follows, T[]=(T[]) new Object[5]; and when you try to compile, the compiler will issue a warning that you are doing an unsafe cast! Of course this is not bug, it is just an implementation problem given for the sake of simplicity and compability when generics were implemented. But raising a compiler warning on a design issue may confuse someone who faced it for the first time. So this is definitely not the end of the list but still Java offers a beatiful syntax, type safety and a realiable easy to learn language. And finally no language or implementation is perfect!   Reference: Infamous Java bugs and pitfalls from our JCG partner Murat Yener at the Developer Chronicles blog. ...

Spring MVC Form Tutorial

This tutorial will show how to handle a form submission in Spring MVC. We will define a controller to handle the page load and the form submission. You can grab the code on GitHub. Prerequisites: You should have a working Spring MVC Application. If you do not already have a working Spring MVC application set up, follow this tutorial. For this tutorial, we are going to make a simple form for subscribing to a newsletter. The form will have the following fields:name – input field age – input field email – input field gender – select drop-down receiveNewsletter – checkbox newsletterFrequency – select drop-downRequirements:The newsletterFrequency drop-down should only be active if the receiveNewsletter checkbox is checked We will not be performing any validations in this example (stay-tuned for future tutorial) When the user submits the form, the same page will reload Reloaded page should display a message that indicates that the submission was successful and shows the saved valuesWhen we’re done, we will have a page that looks like this:First, let’s set up the object we will use to store the subscriber’s information. Create the class Subscriber in package com.codetutr.form. This is a basic Java bean. Notice we are using enumerations to store the gender and newsletter frequency fields. For simplicity, I defined the enums in the same class. Also notice that we are defining the toString. This is just so we can easily get the values to print after submission. package com.codetutr.form;public class Subscriber {private String name; private String email; private Integer age; private Gender gender; private Frequency newsletterFrequency; private Boolean receiveNewsletter;public enum Frequency { HOURLY, DAILY, WEEKLY, MONTHLY, ANNUALLY }public enum Gender { MALE, FEMALE }public String getName() { return name; }public void setName(String name) { = name; }public String getEmail() { return email; }public void setEmail(String email) { = email; }public Integer getAge() { return age; }public void setAge(Integer age) { this.age = age; }public Gender getGender() { return gender; }public void setGender(Gender gender) { this.gender = gender; }public Frequency getNewsletterFrequency() { return newsletterFrequency; }public void setNewsletterFrequency(Frequency newsletterFrequency) { this.newsletterFrequency = newsletterFrequency; }public Boolean getReceiveNewsletter() { return receiveNewsletter; }public void setReceiveNewsletter(Boolean receiveNewsletter) { this.receiveNewsletter = receiveNewsletter; }@Override public String toString() { return "Subscriber [name=" + name + ", age=" + age + ", gender=" + gender + ", newsletterFrequency=" + newsletterFrequency + ", receiveNewsletter=" + receiveNewsletter + "]"; }} Now, let’s create the controller. Create class FormController in package com.codetutr.controller: package com.codetutr.controller;import org.springframework.stereotype.Controller; import org.springframework.ui.Model; import org.springframework.web.bind.annotation.ModelAttribute; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod;import com.codetutr.form.Subscriber; import com.codetutr.form.Subscriber.Frequency;@Controller public class FormController {@ModelAttribute("frequencies") public Frequency[] frequencies() { return Frequency.values(); }@RequestMapping(value="form", method=RequestMethod.GET) public String loadFormPage(Model m) { m.addAttribute("subscriber", new Subscriber()); return "formPage"; }@RequestMapping(value="form", method=RequestMethod.POST) public String submitForm(@ModelAttribute Subscriber subscriber, Model m) { m.addAttribute("message", "Successfully saved person: " + subscriber.toString()); return "formPage"; } } Let’s look at a few things in the code above. First, notice that both request handlers (methods annotated with @RequestMapping) are mapped to the same URL – “form”. The only difference in the mapping is that one handles an HTTP GET request, and the other a POST. The first handler (for the GET request) will be invoked when the user navigates to the “form” page, because they will access the page using a GET request. The POST handler is invoked when the form is submitted (since it will be submitted via HTTP POST to the “form” URL). You could, of course, submit your form to any URL using any HTTP method – just make sure to map your handler accordingly here. Let’s look at the GET handler. It takes a Model, which we populate with an empty Subscriber object. This object is what we will use to populate our form. We are not setting any values here, but if we wanted to, say default the receiveNewsletter checkbox to true and set default newsletter frequency to hourly, we could do: Subscriber subscriber = new Subscriber(); subscriber.setReceiveNewsletter(true); subscriber.setNewsletterFrequency(Frequency.HOURLY); m.addAttribute("subscriber", subscriber); Also note that if we do not add an object called “subscriber” to the model, Spring would complain when we try to access the JSP, because we will be setting up the JSP to bind the form to the “subscriber” model attribute. You would see a JSP error: “Neither BindingResult nor plain target object for bean name ‘subscriber’ available as request attribute” and the JSP would not render. The last thing to look at in the controller code is the @ModelAttribute method. When a method is annotated with @ModelAttribute, Spring runs it before each handler method and adds the return value to the model. We specified in the annotation to add the Frequency values to the model as “frequencies”. This object will be used to populate the newsletter frequency drop-down box in the JSP form. Instead of using the @ModelAttribute method, we could have added the following line to each of the request handlers: m.addAttribute("frequencies", Frequency.values()) Finally, let’s set up the jsp. Create a file called formPage.jsp in WEB-INF/view (or wherever you have configured your JSPs to reside): formPage.jsp <%@ taglib prefix="c" uri="" %> <%@ taglib prefix="form" uri="" %><!DOCTYPE HTML> <html> <head> <title>Sample Form</title> <script src="//"></script> <style> body { background-color: #eee; font: helvetica; } #container { width: 500px; background-color: #fff; margin: 30px auto; padding: 30px; border-radius: 5px; box-shadow: 5px; } .green { font-weight: bold; color: green; } .message { margin-bottom: 10px; } label {width:70px; display:inline-block;} form {line-height: 160%; } .hide { display: none; } </style> </head> <body><div id="container"><h2>Subscribe to The Newsletter!</h2> <c:if test="${not empty message}"><div class="message green">${message}</div></c:if><form:form modelAttribute="subscriber"> <label for="nameInput">Name: </label> <form:input path="name" id="nameInput" /> <br/><label for="ageInput">Age: </label> <form:input path="age" id="ageInput" /> <br/><label for="emailInput">Email: </label> <form:input path="email" id="emailInput" /> <br/><label for="genderOptions">Gender: </label> <form:select path="gender" id="genderOptions"> <form:option value="">Select Gender</form:option> <form:option value="MALE">Male</form:option> <form:option value="FEMALE">Female</form:option> </form:select> <br/><label for="newsletterCheckbox">Newsletter? </label> <form:checkbox path="receiveNewsletter" id="newsletterCheckbox" /> <br/> <label for="frequencySelect">Freq:</label> <form:select path="newsletterFrequency" id="frequencySelect"> <form:option value="">Select Newsletter Frequency: </form:option> <c:forEach items="${frequencies}" var="frequency"> <form:option value="${frequency}">${frequency}</form:option> </c:forEach> </form:select> <br/><br/> <input type="submit" value="Submit" /> </form:form> </div><script type="text/javascript">$(document).ready(function() {toggleFrequencySelectBox(); // show/hide box on page load$('#newsletterCheckbox').change(function() { toggleFrequencySelectBox(); })});function toggleFrequencySelectBox() { if(!$('#newsletterCheckbox').is(':checked')) { $('#frequencySelect').val(''); $('#frequencySelect').prop('disabled', true); } else { $('#frequencySelect').prop('disabled', false); } }</script></body> </html> Let’s walk through the form tags we are using. Notice the line at the top of the page: <%@ taglib prefix="form" uri="" %>. This imports the Spring Form tags we will be using. When we open the form with the <form:form> tag, note that we are specifying the model attribute. This tells Spring to look for an attribute in the Model and bind it to the form. The action and method attributes can also be specified. If unspecified (as in this example), they default to the current URL and “POST”, respectively (just like regular HTML forms). Notice that each of our input fields is using the Spring Form taglib (form: prefix). Each of these fields also specifies a path attribute. This must correspond to a getter or setter of the model attribute (in our case, the Subscriber class) according to the standard Java bean convention (get/is, set prefixed to field name with first letter capitalized). When the page is loaded, the input fields are populated by Spring, which calls the getter of each field bound to an input field. When the form is submitted, the setters are called to save the values of the form to the object. The <form:input> tags are pretty self explanatory. Notice the two instances of <form:select> used. In the first select drop-down, for the gender field, notice that we manually list all of the options. In the newsletter frequency select drop-down, though, we loop through the frequencies model attribute (remember we added that to the model through the @ModelAttribute-annotated method in the Controller) and add each item as an option in the drop-down. Spring automatically will bind the form values to the enums when the form is submitted as long as the value of the selected option is a valid enum name. When the form is submitted, the POST handler in the controller is invoked. The form is automatically bound to the subscriber argument that we passed in. The @ModelAttribute annotation isn’t actually necessary here. I will write more about that in another post. There you have it! I strongly recommend you download the source and run the code. Post any questions you have in the comments below. Full Source: ZIP, GitHub To run the code from this tutorial: Must have Gradle installed. Download the ZIP. Extract. Open command prompt to extracted location. Run gradle jettyRunWar. Navigate in browser to http://localhost:8080/form. ResourcesSpring Form TagLib Reference Documentation DZone – Spring Form Tag Tutorial  Reference: Spring MVC Form Tutorial from our JCG partner Steve Hanson at the CodeTutr blog. ...

HotSpot GC Thread CPU footprint on Linux

The following question will test your knowledge on garbage collection and high CPU troubleshooting for Java applications running on Linux OS. This troubleshooting technique is especially crucial when investigating excessive GC and / or CPU utilization. It will assume that you do not have access to advanced monitoring tools such as Compuware dynaTrace or even JVisualVM. Future tutorials using such tools will be presented in the future but please ensure that you first master the base troubleshooting principles. Question: How can you monitor and calculate how much CPU % each of the Oracle HotSpot or JRockit JVM garbage collection (GC) threads is using at runtime on Linux OS? Answer: On the Linux OS, Java threads are implemented as native Threads, which results in each thread being a separate Linux process. This means that you are able to monitor the CPU % of any Java thread created by the HotSpot JVM using the top –H command (Threads toggle view). That said, depending of the GC policy that you are using and your server specifications, the HotSpot & JRockit JVM will create a certain number of GC threads that will be performing young and old space collections. Such threads can be easily identified by generating a JVM thread dump. As you can see below in our example, the Oracle JRockit JVM did create 4 GC threads identified as “(GC Worker Thread X)”.===== FULL THREAD DUMP ===============Fri Nov 16 19:58:36 2012BEA JRockit(R) R27.5.0-110-94909-1.5.0_14-20080204-1558-linux-ia32"Main Thread" id=1 idx=0x4 tid=14911 prio=5 alive, in native, waiting-- Waiting for notification on: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[fat lock]at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)at java/lang/Object.wait(J)V(Native Method)at java/lang/Object.wait( weblogic/t3/srvr/T3Srvr.waitForDeath(^-- Lock released while waiting: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[fat lock] at weblogic/t3/srvr/ at weblogic/Server.main( jrockit/vm/RNI.c2java(IIIII)V(Native Method)-- end of trace"(Signal Handler)" id=2 idx=0x8 tid=14920 prio=5 alive, in native, daemon"(GC Main Thread)" id=3 idx=0xc tid=14921 prio=5 alive, in native, native_waiting, daemon"(GC Worker Thread 1)" id=? idx=0x10 tid=14922 prio=5 alive, in native, daemon"(GC Worker Thread 2)" id=? idx=0x14 tid=14923 prio=5 alive, in native, daemon"(GC Worker Thread 3)" id=? idx=0x18 tid=14924 prio=5 alive, in native, daemon"(GC Worker Thread 4)" id=? idx=0x1c tid=14925 prio=5 alive, in native, daemon……………………… Now let’s put all of these principles together via a simple example. Step #1 – Monitor the GC thread CPU utilization The first step of the investigation is to monitor and determine:Identify the native Thread ID for each GC worker thread shown via the Linux top –H command.Identify the CPU % for each GC worker thread.Step #2 – Generate and analyze JVM Thread Dumps At the same time of Linux top –H, generate 2 or 3 JVM Thread Dump snapshots via kill -3 <Java PID>.Open the JVM Thread Dump and locate the JVM GC worker threads.Now correlate the “top -H” output data with the JVM Thread Dump data by looking at the native thread id (tid attribute).As you can see in our example, such analysis did allow us to determine that all our GC worker threads were using around 20% CPU each. This was due to major collections happening at that time. Please note that it is also very useful to enable verbose:gc as it will allow you to correlate such CPU spikes with minor and major collections and determine how much your JVM GC process is contributing to the overall server CPU utilization.   Reference: HotSpot GC Thread CPU footprint on Linux from our JCG partner Pierre-Hugues Charbonneau at the Java EE Support Patterns blog. ...

Going Dawkins on god objects

Meet the enemy. Steaming stinking jungle crushing all about you, insects infesting the air, strange grunts shuddering in the foliage, you pause deep in uncharted refactoring, far from respite, far from home, far from help. Sweat oozes from all pores. Your machete, notched and dulled from ten thousand hacks, hangs weary in your calloused grip while your mind mumbles to itself, exhausted. Behind you no track records your passing: the countless vines severed, the countless dependencies torn asunder, the countless decrepit classes heaved aside, none of these has changed the tangling madness. All your agonized restructuring seems wasted, meaningless, amid the yelping brutes scuttling unglimpsed beyond the trees.  Then you see the darkness. Lost in toil, you had not noticed it as you approached, its form an expansive yet subtle shading. Dread floods your soul. You stagger through the treeline, drawn to the horror, and the light begins to fail with each step. Weak slashing fails to keep the briars from your flesh but you push on. You have to see it. You must see it. A final wall of sticky vegetation parts and you stumble through. The vista opens before you. The monster reveals itself. God object. Immeasurably vast, the foul beast sprawls from forest floor to canopy, smothering the sky. Tendrils snake everywhere, radiating from the central denseness to choke every class they touch. Worse still, fat tuberous dependencies thrash towards the god object’s gigantic core from all sides, an insanity of twisting and coiling and piercing. Defeated, you collapse to your knees, machete spilling from your hand. Despair pounces. You bow your head. There, on the ground before you, something glints, something silver and out-of-place. With your last strength you reach out to pick up the metal tag. Faint writing scores its surface. It reads, “”. Scales and sightings.To the term, “God object,” many object. The animal in question is not at all an object but a class, not an electrically-driven choreography of registers pinging data across high-speed buses but a file of text, albeit a commodious one. Nor would many quite agree with the honourable Wikipedia’s claim that our quarry need have, ” … most of a program’s overall functionality … coded into a single ‘all-knowing’ object, which maintains most of the information about the entire program and provides most of the methods for manipulating this data.” Given today’s corporate behemoths, a single class housing the better part of a banking system, for example, would be a thing of splendid wonder. Instead, most would consider a god object to be any class that was just doing far too much, had far too many responsibilities or just had far too many lines of code. This begs the question: what is far too much? Few would consider a class of two hundred lines of text far too anything. It might be, of course: outliers and rare exceptions exist, but a reasonable class of two hundred lines would hardly raise suspicions purely because of its size. A class of five hundred lines might meet some jeering, some stern interrogation; yet it, too, could sail through a review if justified by a knowledgeable designer. There are always reasons for these things. At a thousand lines long, however, a class has crossed an unspoken boundary. Good taste has been snubbed, good breeding insulted. Someone’s whipped out a can of lager at the wine-tasting. A thousand lines just seems so breakupable. Has this class really so focused a single yet gargantuan responsibility that it could not be split in two? Really? “Now you’re just being silly,” is certainly the politest version of comment heard when a class of fifteen hundred lines steps out of the taxi and onto the reviewers’ red carpet. The paparazzi flash their cameras but disbelief rather than admiration motivates their whirring shutters. Two thousand lines perhaps – just perhaps – denotes ascension to godliness. It may not accommodate most of the program’s functionality but dear, oh dear a class wily enough to evade reviewer after blade-wielding reviewer and grow so large almost deserves a shrine or two erected in its honour. That such a class might justify its own non-decomposability would strain the belief of even the most gullible software architect. God objects, furthermore, fall into two categories. The first is the autonomous god object, which, while screaming demented abuse at all good structure principles, at least has the grace to do so by itself, secluded in a corner somewhere. Few classes depend on this type of god object; one or two other classes must prod it into action, after which it will bluster about doing an enormous amount of stuff, but at least splitting it into smaller classes will not ripple back up through the system precisely because so few other classes depend on it. Its relative isolation makes this type of god object the lesser of the two evils. The communal god object, the second category, boasts a vast number of dependent classes. This type can have twenty, thirty or even forty other classes directly dependent on it, all of which cover their eyes and inhale through clenched teeth when a programmer attempts a decomposition. Listen for the crunch-crunch-crunch as you approach for the floors about these god objects lie littered with the shards of shattered careers. Have you ever seen one? Have you ever seen a communal god object? If not, sit back and find something tough to bite down on … Behold, the gorgon!No image guarantees the presence of the beast. Structural diagrams can only ever raise not answer questions. A cursory trek through the MavenProject class itself reveals, however, a full 2200 lines of code, four times what some consider a healthy size and practically a package in its own right. The question is: when face-to-face with such a bruiser, what should you do? Programmers usually do one of three things. First, they may simply look the other way, a common solution. Second, they may start ripping out what methods they can into smaller classes. Both options have their merits. The third option, though, often goes overlooked. This option acknowledges the dynamism of the god object; they grow so big because they do just that: they grow. They seldom stand still and they usually do not stop gobbling up functionality just because you decide to step in and take control. With the presumption of continued growth, option two looks shaky: like a hydra, the god object watches the classes you chop off soon themselves begin to writhe and gobble and grow. Cohesion degrades and with all those dependencies skewering directly into the new implementation classes coupling becomes problematic. The third option recommends that you do not reduce the size of the god object at all. At least initially. Instead, you merely begin creating small interfaces – implemented by the god object – and have erstwhile clients of the god object redirect their attention to these interfaces. Opinions divide on the nature of these small interfaces. One camp suggests analyzing the god object’s functions and grouping them semantically. This has the advantage of keeping the new interfaces disjoint, sharing no common function declarations, but the disadvantage of having clients receive interfaces all of whose functions they probably will not use. The other camp suggests creating a new interface for each client package (or significant class), making the interfaces more client- than provider-specific. This has the advantage that clients use precisely and fully the interfaces that they receive but the disadvantage that many interfaces might declare the same functions. In practice, some begin with the second approach and when finished gather duplicated function declarations into common, extended interfaces. However achieved, this is but the first step. Once the penultimate dependency on the god object snaps still the knives should remained sheathed. The beast must first be made package-private (Java’s default access modifier) so that future clients cannot bypass the interfaces and then preferably be moved to its own, new package, leaving the interfaces behind. Only then, when the god object is isolated from all else and with the interfaces now revealing themselves as a Facade, can the dissections begin. That might sound like a lot of work. It is. No one said this would be easy. The final configuration, however, offers a Facade of interfaces to clients untroubled by decoupled implementation refactorings, and a separate package from which unearthly screams radiate throughout the entire program. For a while. Just for fun, we can take an X-ray of our MavenProject class to see what its guts look like. Often large classes suggest their own extractions and as we see from figure 2 that deepCopy() function looks tempting.Summary. God objects: don’t. Photo credit attribution.CC Image Jungle and The Sun courtesy of yassina on Flickr. CC Image Perseus triumphant with Medusa head courtesy of Monitotxi on Flickr.  Reference: Going Dawkins on god objects from our JCG partner Edmund Kirwan at the A blog about software. blog. ...

Architecture-Breaking Bugs – when a Dreamliner becomes a Nightmare

The history of computer systems is also the history of bugs, including epic, disastrous bugs that have caused millions of $ in damage and destruction and even death, as well as many other less spectacular but expensive system and project failures. Some of these appear to be small and stupid mistakes, like the infamous Ariane 5 rocket crash, caused by a one-line programming error. But a one-line programming error, or any other isolated mistake or failure, cannot cause serious damage to a large system, without fundamental failures in architecture and design, and failures in management.Boeing’s 787 Dreamliner Going Nowhere The Economist, Feb 26 2013 These kinds of problems are what Barry Boehm calls “Architecture Breakers”: where a system’s design doesn’t hold up in the real world, when you run face-first into a fundamental weakness or a hard limit on what is possible with the approach that you took or the technology platform that you selected. Architecture Breakers happen at the edges – or beyond the edges – of the design, off of the normal, nominal, happy paths. The system works, except for a “one in a million” exceptional error, which nobody takes seriously until a “once in a million” problem starts happening every few days. Or the system crumples under an unexpected surge in demand, demand that isn’t going to go away unless you can’t find a way to quickly scale the system to keep up – and if you can’t, you won’t have a demand problem any more because those customers won’t be coming back. Or what looks like a minor operational problem turns out to be the first sign of a fundamental reliability or safety problem in the system.Dreamliner is Troubled by Questions about Safety NY Times, Jan 10, 2013 Finding Architecture Breakers It starts off with a nasty bug or an isolated operational issue or a security incident. As you investigate and start to look deeper you find more cases, gaping holes in the design, hard limits to what the system can do, or failures that can’t be explained and can’t be stopped. The design starts to unravel as each problem opens up to another problem. Fixing it right is going to take time and money, maybe even going back to the drawing board and revisiting foundational architectural decisions and technology choices. What looked like a random failure or an ugly bug just turned into something much uglier, and much much more expensive.Deepening Crisis for the Boeing 787 NY Times, Jan 17 2013 What makes these problems especially bad is that they are found late, way past design and even past acceptance testing, usually when the system is already in production and you have a lot of real customers using it to get real work done. This is when you can least afford to encounter a serious problem. When something does go wrong, it can be difficult to recognize how serious it is right away. It can take two or three or more failures before you realize – and accept – how bad things really are and before you see enough of a pattern to understand where the problem might be.Boeing Batteries Said to Fail 10 Times Before Incident Bloomberg, Jan 30 2013 By then you may be losing customers and losing money and you’re under extreme pressure to come up with a fix, and nobody wants to hear that you have to stop and go back and rewrite a piece of the system, or re-architect it and start again – or that you need more time to think and test and understand what’s wrong and what your options are before you can even tell them how long it might take and how much it could cost to fix things.Regulators Around the Globe Ground Boeing 787s NY Times, Jan 18 2013 What can Break your Architecture? Most Architecture Breakers are fundamental problems in important non-functional aspects of a system:Stability and data integrity: some piece of the system won’t stay up under load or fails intermittently after the system has been running for hours or days or weeks, or you lost critical customer data or you can’t recover and restore service fast enough after an operational failure. Scalability and throughput: the platform (language or container or communications fabric or database – or all of them) are beautiful to work with, but can’t keep up as more customers come in, even if you throw more hardware at it. Ask Twitter about trying to scale-out Ruby or Facebook about scaling PHP or anyone who has ever tried to scale-out Oracle RAC. Latency – requirements for real-time response-time/deadline satisfaction escalate, or you run into unacceptable jitter and variability (you chose Java as your run-time platform, what happens when GC kicks in?). Security: you just got hacked and you find out that the one bug that an attacker exploited is only the first of hundreds or thousands of bugs that will need to be found and fixed, because your design or the language and the framework that you picked (or the way that you used it) is as full of security holes as Swiss cheese.These problems can come from misunderstanding what an underlying platform technology or framework can actually do – what the design tolerances for that architecture or technology are. Or from completely missing, overlooking, ignoring or misunderstanding an important aspect of the design. These aren’t problems that you can code your way out of, at least not easily. Sometimes the problem isn’t in your code any ways: it’s in a third party platform technology that can’t keep up or won’t stay up. The language itself, or an important part of the stack like the container, database, or communications fabric, or whatever you are depending on for clustering and failover or to do some other magic. At high scale in the real world, almost any piece of software that somebody else wrote can and will fall short of what you really need, or what the vendor promised.Boeing, 787 Battery Supplier at Odds over Fixes Wall Street Journal, Feb 27 2013 You’ll have to spend time working with a vendor (or sometimes with more than one vendor) and help them understand your problem, and get them to agree that it’s really their problem, and that they have to fix it, and if they can’t fix it, or can’t fix it quickly enough, you’ll need to come up with a Plan B quickly, and hope that your new choice won’t run into other problems that may be just as bad or even worse. How to Avoid Architecture Breakers Architecture Breakers are caused by decisions that you made early and got wrong – or that you didn’t make early enough, or didn’t make at all. Boehm talks about Architecture Breakers as part of an argument against Simple Design – that many teams, especially Agile teams, spend too much time focused on the happy path, building new features to make the customer happy, and not enough time on upfront architecture and thinking about what could go wrong. But Architecture Breakers have been around a lot longer than Agile and simple design: in Making Software (Chapter 10 Architecting: How Much and When), Boehm goes back to the 1980s when he first recognized these kinds of problems, when Structured Programming and later Waterfall were the “right way” to do things. Boehm’s solution is more and better architecture definition and technical risk management through Spiral software development: a lifecycle with architecture upfront to identify risk areas, which are then explored through iterative, risk-driven design, prototyping and development in multiple stages. Spiral development is like today’s iterative, incremental development methods on steroids, using risk-based architectural spikes, but with much longer iterative development and technical prototyping cycles, more formal risk management, more planning, more paperwork, and much higher costs. Bugs like these can’t all be solved by spending more time on architecture and technical risk management upfront – whether through Spiral development or a beefed up, disciplined Agile development approach. More time spent upfront won`t help if you make naïve assumptions about scalability, responsiveness or reliability or security; or if you don’t understand these problems well enough to identify the risks. Architecture Breakers won’t be found in design reviews – because you won’t be looking for something that you don’t know could a problem – unless maybe you are running through structured failure modelling exercises like FMEA (Failure mode and effect analysis) or FMECA (Failure mode, effects and criticality analysis), which force you to ask hard questions, but which few people outside of regulated industries have even heard about. And Architecture Breakers can’t all be caught in testing, even extended longevity/soak testing and extensive fuzzing and simulated failures and fault injection and destructive testing and stress testing – even if all the bugs that are found this way are taken seriously (because these kinds of extreme tests are often considered unrealistic). You have to be prepared to deal with Architecture Breakers. Anticipating problems and partitioning your architecture using something like the Stability Patterns in Michael Nygard’s excellent book Release It! will at least keep serious run-time errors from spreading and taking an entire system out (these strategies will also help with scaling and with containing security attacks). And if and when you do see a “once in a million” error in reviews or testing or production, understand how serious it can be, and act right away – before a Dreamliner turns into a nightmare.   Reference: Architecture-Breaking Bugs – when a Dreamliner becomes a Nightmare from our JCG partner Jim Bird at the Building Real Software blog. ...

Scala traits implementation and interoperability. Part II: Traits linearization

This is a continuation of Scala traits implementation and interoperability. Part I: Basics. Dreadful diamond problem can be mitigated using Scala traits and a process called linearization. Take the following example:                 trait Base { def msg = "Base" } trait Foo extends Base { abstract override def msg = "Foo -> " + super.msg } trait Bar extends Base { abstract override def msg = "Bar -> " + super.msg } trait Buzz extends Base { abstract override def msg = "Buzz -> " + super.msg } class Riddle extends Base with Foo with Bar with Buzz { override def msg = "Riddle -> " + super.msg } Now let me ask you a little question: what is the output of (new Riddle).msg?Riddle -> Base Riddle -> Buzz -> Base Riddle -> Foo -> Base Riddle -> Buzz -> Bar -> Foo -> BaseIt’s not (1) because Base.msg is overriden by all traits we extend, so that shouldn’t be a surprise. But it’s also not (2) and (3). One might expect that either Buzz or Foo is printed, remembering that you can stack traits and either first or last (actually: last) wins. So why Riddle -> Buzz -> Base is incorrect? Isn’t Buzz.msg calling super.msg and Buzz explicitly states Base being it’s parent? There is a bit of magic here. When you stack multiple traits as we did (extends Base with Foo with Bar with Buzz) Scala compiler orders them (linearizes) so that there is always one path from every class to the parent (Base). The order is determined by the reversed order of traits mixed in (last one wins and becomes first). Why would you ever…? Turns out stackable traits are great for implementing several layers of decoration around real object. You can easily add decorators and move them around. We have a simple calculator abstraction and one implementation: trait Calculator { def increment(x: Int): Int } class RealCalculator extends Calculator { override def increment(x: Int) = { println(s"increment($x)") x + 1 } } We came up with three aspect we would like to selectively apply depending on some circumstances: logging all increment() invocations, caching and validation. First let’s define all of them: trait Logging extends Calculator { abstract override def increment(x: Int) = { println(s"Logging: $x") super.increment(x) } } trait Caching extends Calculator { abstract override def increment(x: Int) = if(x < 10) { //silly caching... println(s"Cache hit: $x") x + 1 } else { println(s"Cache miss: $x") super.increment(x) } } trait Validating extends Calculator { abstract override def increment(x: Int) = if(x >= 0) { println(s"Validation OK: $x") super.increment(x) } else throw new IllegalArgumentException(x.toString) } Creating "raw" calculator is of course possible: val calc = new RealCalculator calc: RealCalculator = RealCalculator@bbd9e6 scala> calc increment 17 increment(17) res: Int = 18 But we are free to mix-in as many trait mixins as we want, in any order: scala> val calc = new RealCalculator with Logging with Caching with Validating calc: RealCalculator with Logging with Caching with Validating = $anon$1@1aea543 scala> calc increment 17 Validation OK: 17 Cache miss: 17 Logging: 17 increment(17) res: Int = 18 scala> calc increment 9 Validation OK: 9 Cache hit: 9 res: Int = 10 See how subsequent mixins kick in? Of course each mixin can skip super call, e.g. on cache hit or validation failure. Just to be clear here - it doesn't matter that each of decorating mixins have Calculator defined as a base trait. super.increment() is always routed to next trait in stack (previous one in the class declaration). That means super is more dynamic and dependant on target usage rather than declaration. We will explain this later but first another example: let's put logging before caching so no matter whether there was cache hit or miss, we always get logging. Moreover we "disable" validation by simply skipping it: scala> class VerboseCalculator extends RealCalculator with Caching with Logging defined class VerboseCalculator scala> val calc = new VerboseCalculator calc: VerboseCalculator = VerboseCalculator@f64dcd scala> calc increment 42 Logging: 42 Cache miss: 42 increment(42) res: Int = 43 scala> calc increment 4 Logging: 4 Cache hit: 4 res: Int = 5 I promised to explain how stacking works underneath. You should be really curious how this "funky" super is implemented as it cannot simply rely on invokespecial bytecode instruction, used with normal super. Unfortunately it's complex, but worth to know and understand, especially when stacking doesn't work as expected. Calculator and RealCalculator compile pretty much exactly to what you might have expected: public interface Calculator { int increment(int i); } public class RealCalculator implements Calculator { public int increment(int x) { return x + 1; } } But how would the following class be implemented? class FullBlownCalculator extends RealCalculator with Logging with Caching with Validating Let's start from the class itself: public class FullBlownCalculator extends RealCalculator implements Logging, Caching, Validating { public int increment(int x) { return Validating$class.increment(this, x); } public int Validating$$super$increment(int x) { return Caching$class.increment(this, x); } public int Caching$$super$increment(int x) { return Logging$class.increment(this, x); } public int Logging$$super$increment(int x) { return super.increment(x); } } Can you see what's going on here? Before I show the implementations of all these *$class classes, spend a little bit of time confronting class declaration (trait order in particular) and these awkward *$$super$* methods. Here is the missing piece that will allow us to connect all the dots: public abstract class Logging$class { public static int increment(Logging that, int x) { return that.Logging$$super$increment(x); } } public abstract class Caching$class { public static int increment(Caching that, int x) { return that.Caching$$super$increment(x); } } public abstract class Validating$class { public static int increment(Validating that, int x) { return that.Validating$$super$increment(x); } } Not helpful? Let's go slowly through the first step. When you call FullBlownCalculator, according to trait stacking rules, RealBlownCalculator.increment() should call Validating.increment(). As you can see, Validating.increment() forwards this (itself) to static Validating$class.increment() hidden class. This class expects an instance of Validating, but since FullBlownCalculator also extends that trait, passing this is fine. Now look at the Validating$class.increment(). It barely forwards FullBlownCalculator.Validating$$super$increment(x). And when we, again, go back to FullBlownCalculator we will notice that this method delegates to static Caching$class.increment(). From here the process is similar. Why the extra delegation through static method? Mixins don't know which class is going to be next in the stack ("next super"). Thus they simply delegate to appropriate virtual $$super$ family of methods. Each class using these mixins is obligated to implement them, providing correct "super". To put that into perspective: compiler cannot simply delegate straight from Validating$class.increment() to Caching$class.increment(), even though that's the FullBlowCalculator workflow. However if we create another class that reverses these mixins (RealCalculator with Validating with Caching) hardcoded dependency between mixins is no longer valid. This it's the responsibility of the class, not mixin, to declare the order. If you still don't follow, here is the complete call stack for FullBlownCalculator.increment(): val calc = new FullBlownCalculator calc increment 42 FullBlownCalculator.increment(42) `- Validating$class.increment(calc, 42) `- Validating.Validating$$super$increment(42) (on calc) `- Caching$class.increment(calc, 42) `- Caching.Caching$$super$increment(42) (on calc) `- Logging$class.increment(calc, 42) `- Logging.Logging$$super$increment(42) (on calc) `- super.increment(42) `- RealCalculator.increment(42) (on calc) Now you see why it's called "linearization"!   Reference: Scala traits implementation and interoperability. Part II: Traits linearization from our JCG partner Tomasz Nurkiewicz at the Java and neighbourhood blog. ...
Java Code Geeks and all content copyright © 2010-2015, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.