Featured FREE Whitepapers

What's New Here?


right-pad values with XSLT

In this post an XSLT function that can be used to right-pad the value of an element with a chosen character to a certain length. No rocket science but this might become handy again so by putting it down here I don’t have to reinvent it later. The function itself looks like:               <xsl:stylesheet version="2.0" xmlns:functx="http://my/functions" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:function name="functx:pad-string-to-length" as="xsd:string"> <xsl:param name="stringToPad" as="xsd:string?"/> <xsl:param name="padChar" as="xsd:string"/> <xsl:param name="length" as="xsd:integer"/> <xsl:sequence select=" substring( string-join ( ($stringToPad, for $i in (1 to $length) return $padChar) ,'') ,1,$length) "/> </xsl:function></xsl:stylesheet> And with this function available you can use it like: <xsl:template match="/"> <xsl:value-of select="functx:pad-string-to-length(//short_value, '0', 12)" /> </xsl:template> The input XML like: <test> <short_value>123</short_value> </test> will give as a result in this case: 123000000000 By the way, this function only works with XSLT2!Reference: right-pad values with XSLT from our JCG partner Pascal Alma at the The Pragmatic Integrator blog....

Java Tutorial Through Katas: Mars Rover

A programming kata is an exercise which helps a programmer hone his skills through practice and repetition. This article is part of the series Java Tutorial Through Katas. The article assumes that the reader already has experience with Java, that he is familiar with the basics of unit tests and that he knows how to run them from his favorite IDE (mine is IntelliJ IDEA). Tests that prove that the solution is correct are displayed below. Recommended way to solve this kata is to use test-driven development approach (write the implementation for the first test, confirm that it passes and move to the next). Once all of the tests pass, the kata can be considered solved. For more information about best practices, please read the Test Driven Development (TDD): Best Practices Using Java Examples. One possible solution is provided below the tests. Try to solve the kata by yourself first. Mars Rover Develop an api that moves a rover around on a grid. Rules:You are given the initial starting point (x,y) of a rover and the direction (N,S,E,W) it is facing. The rover receives a character array of commands. Implement commands that move the rover forward/backward (f,b). Implement commands that turn the rover left/right (l,r). Implement wrapping from one edge of the grid to another. (planets are spheres after all) Implement obstacle detection before each move to a new square. If a given sequence of commands encounters an obstacle, the rover moves up to the last possible point and reports the obstacle.Tests Following is a set of unit tests that can be used to solve this kata in the TDD fashion. package com.technologyconversations.kata.marsrover;import org.junit.Before; import org.junit.Test;import java.util.ArrayList; import java.util.Arrays; import java.util.List;import static org.assertj.core.api.Assertions.*;/* Source: http://dallashackclub.com/roverDevelop an api that moves a rover around on a grid. * You are given the initial starting point (x,y) of a rover and the direction (N,S,E,W) it is facing. * - The rover receives a character array of commands. * - Implement commands that move the rover forward/backward (f,b). * - Implement commands that turn the rover left/right (l,r). * - Implement wrapping from one edge of the grid to another. (planets are spheres after all) * - Implement obstacle detection before each move to a new square. * If a given sequence of commands encounters an obstacle, the rover moves up to the last possible point and reports the obstacle. */ public class RoverSpec {private Rover rover; private Coordinates roverCoordinates; private final Direction direction = Direction.NORTH; private Point x; private Point y; private List<Obstacle> obstacles;@Before public void beforeRoverTest() { x = new Point(1, 9); y = new Point(2, 9); obstacles = new ArrayList<Obstacle>(); roverCoordinates = new Coordinates(x, y, direction, obstacles); rover = new Rover(roverCoordinates); }@Test public void newInstanceShouldSetRoverCoordinatesAndDirection() { assertThat(rover.getCoordinates()).isEqualToComparingFieldByField(roverCoordinates); }@Test public void receiveSingleCommandShouldMoveForwardWhenCommandIsF() throws Exception { int expected = y.getLocation() + 1; rover.receiveSingleCommand('F'); assertThat(rover.getCoordinates().getY().getLocation()).isEqualTo(expected); }@Test public void receiveSingleCommandShouldMoveBackwardWhenCommandIsB() throws Exception { int expected = y.getLocation() - 1; rover.receiveSingleCommand('B'); assertThat(rover.getCoordinates().getY().getLocation()).isEqualTo(expected); }@Test public void receiveSingleCommandShouldTurnLeftWhenCommandIsL() throws Exception { rover.receiveSingleCommand('L'); assertThat(rover.getCoordinates().getDirection()).isEqualTo(Direction.WEST); }@Test public void receiveSingleCommandShouldTurnRightWhenCommandIsR() throws Exception { rover.receiveSingleCommand('R'); assertThat(rover.getCoordinates().getDirection()).isEqualTo(Direction.EAST); }@Test public void receiveSingleCommandShouldIgnoreCase() throws Exception { rover.receiveSingleCommand('r'); assertThat(rover.getCoordinates().getDirection()).isEqualTo(Direction.EAST); }@Test(expected = Exception.class) public void receiveSingleCommandShouldThrowExceptionWhenCommandIsUnknown() throws Exception { rover.receiveSingleCommand('X'); }@Test public void receiveCommandsShouldBeAbleToReceiveMultipleCommands() throws Exception { int expected = x.getLocation() + 1; rover.receiveCommands("RFR"); assertThat(rover.getCoordinates().getX().getLocation()).isEqualTo(expected); assertThat(rover.getCoordinates().getDirection()).isEqualTo(Direction.SOUTH); }@Test public void receiveCommandShouldWhatFromOneEdgeOfTheGridToAnother() throws Exception { int expected = x.getMaxLocation() + x.getLocation() - 2; rover.receiveCommands("LFFF"); assertThat(rover.getCoordinates().getX().getLocation()).isEqualTo(expected); }@Test public void receiveCommandsShouldStopWhenObstacleIsFound() throws Exception { int expected = x.getLocation() + 1; rover.getCoordinates().setObstacles(Arrays.asList(new Obstacle(expected + 1, y.getLocation()))); rover.getCoordinates().setDirection(Direction.EAST); rover.receiveCommands("FFFRF"); assertThat(rover.getCoordinates().getX().getLocation()).isEqualTo(expected); assertThat(rover.getCoordinates().getDirection()).isEqualTo(Direction.EAST); }@Test public void positionShouldReturnXYAndDirection() throws Exception { rover.receiveCommands("LFFFRFF"); assertThat(rover.getPosition()).isEqualTo("8 X 4 N"); }@Test public void positionShouldReturnNokWhenObstacleIsFound() throws Exception { rover.getCoordinates().setObstacles(Arrays.asList(new Obstacle(x.getLocation() + 1, y.getLocation()))); rover.getCoordinates().setDirection(Direction.EAST); rover.receiveCommands("F"); assertThat(rover.getPosition()).endsWith(" NOK"); }} One possible solution is following. package com.technologyconversations.kata.marsrover;/* Method receiveCommands should be used to transmit commands to the rover. */ public class Rover {private Coordinates coordinates; public void setCoordinates(Coordinates value) { coordinates = value; } public Coordinates getCoordinates() { return coordinates; }public Rover(Coordinates coordinatesValue) { setCoordinates(coordinatesValue); }public void receiveCommands(String commands) throws Exception { for (char command : commands.toCharArray()) { if (!receiveSingleCommand(command)) { break; } } }public boolean receiveSingleCommand(char command) throws Exception { switch(Character.toUpperCase(command)) { case 'F': return getCoordinates().moveForward(); case 'B': return getCoordinates().moveBackward(); case 'L': getCoordinates().changeDirectionLeft(); return true; case 'R': getCoordinates().changeDirectionRight(); return true; default: throw new Exception("Command " + command + " is unknown."); } }public String getPosition() { return getCoordinates().toString(); }} Full source is located in the GitHub repo [https://github.com/vfarcic/mars-rover-kata-java). Above code presents only the code of the main class. There are several other classes/objects with their corresponding specification. Besides tests and implementation, repository includes build.gradle that can be used, among other things, to download AssertJ dependencies and run tests README.md contains short instructions how to set up the project. What was your solution? Post it as a comment so that we can compare different ways to solve this kata.Reference: Java Tutorial Through Katas: Mars Rover from our JCG partner Viktor Farcic at the Technology conversations blog....

Why Your IoT Product Strategy Needs to Include Open Source

For the last two years, I have been talking about why open source will be critical to the success of the Internet of Things.  The current state of IoT/M2M is a lot of propriertary platforms and protocols. This can’t last and won’t win in the long term. This week during a webinar about the new Vorto IoT project from Bosch, I saw the best illustration of why companies that don’t include open source in their product strategy will eventually fail.  Check out this slide about the Bosch IoT Platform Strategy:        Bosch is one of the leading industrial companies in the IoT industry. They definitely get it and their analysis of the market is definitely worth considering. Consider each of their assumptions very carefully:2-5 major IoTS platforms (in next 5-7 years) – At the start of every new technology innovation there are lots of different platforms that are developed. However, overtime the industry consolidates around 2-5 key providers, ex databases, web servers, Java servers, etc.   This will happen in IoT. At least one of them will be Open Source – Open source has proven to be a provider of production quality software. In many markets, open source is the dominant supplier.  There is no reason to believe that this will not be the case in IoT. Bosch not able to develop one of these proprietary platforms alone and customers/partners would not accept it – Developing a proprietary platform takes a LOT of development resources but more importantly a LOT of marketing, sales, and business development resources. Even a company as large as Bosch recognizes this fact. Companies like Google, Apple, IBM, SAP, Oracle, Salesforce, Microsoft plus some others may have the resources and skills to compete but most companies don’t. Most companies will need to identify their key value add for IoT. Providing a platform is not going to be a value add that is sustainable in the long-term. No risk/dependency on proprietary 3rd party platform – Bosch and other companies still need an IoT platform, so they are making a make vs buy decision. If they decide to not Make  (see #3) then the buy decision comes down to a proprietary platform or an open source platform. Considering #2, deciding to go with an open source platform provides a lot more flexibility and less risk of being dependent on another company.If you are setting a product strategy for an IoT product, you will be faced with a Make vs Buy decision.  I think Bosch makes a pretty compelling case for open source. More importantly, Bosch has decided to be a leader in open source, ensuring they have a significant role and stake in the success. Reason #2 The other reason open source is going to win is captured in by Matt Asay in his recent article. The answer of course is: Developers.  As Matt points out ‘Developers aren’t going to go for proprietary standards.’  And as Matt points out, developers are attracted to code:But let’s be clear: None of these companies lining up to join this or that foundation will prove dispositive in cementing any particular standard as theopen source standard. Developers do that. And developers are attracted by tools and platforms that make them more productive, fast. Getting a marquee list of donors to a foundation is meaningless if the foundation doesn’t generate code that appeals to developers.This is why what we are doing at Eclipse IoT is so important. We have code, sandbox servers and tutorials to make it easy for developers to get start with IoT. It is clear code and openness will win in IoT. Join us in creating an amazing IoT open source community.Reference: Why Your IoT Product Strategy Needs to Include Open Source from our JCG partner Ian Skerrett at the Ian Skerrett’s blog blog....

What Happens When a Contractor Wants to Go Full time

This just happened to me recently.  I have been looking for a job actively for the last six months.  One of the major questions I had were if I wanted to stay in a government contractor firm or go full time in a private company.  With contracting, one knows when is the last day.  On the other hand, I know there is no plan to dump me by a certain date.  That may be too harsh but most contracting firms just do not have the money to keep an employee that is not billing to some account besides overhead.         The Real Problem One of the great things about being a contractor is that about every five years or so, one is doing something different.  It is exciting and one learns a lot.  The problem with that is you get a Senior Developer with four or three years of this and that.  I have become a jack-of-all-trades-and-a-master-of-none developer.  See where this is going?  I get turned down by companies that want ten years experience on a certain technology.  I simply do not have that kind of experience.  The only companies that get excited about that kind of experience were really only contracting companies with “long term” contracts of six months plus.  I am working on a five year contract that just got a six month extension and I have benefits with that job.  Can you give me that kind of job?  The answer was “No.” Solution After talking with one of the many recruiters that I had.  I really enjoyed working with him.  One of the best recruiters I have ever had.  No, he did not land me my new job but I could not have done it without him.  If you are in the market and know Java, please contact me and I will get you his information.  If he cannot help, he will know someone that does.  We worked out a strategy to convince managers that I was worth the risk.  I distilled that talk into the following things:I pick up technology quick – As a contractor, when I get into a new contract, I am already behind.  If I do not understand what is going on, the customer will not be happy.  If the customer is not happy, they may start asking for someone else.  Except for four to six months, I have been doing this my entire career so I learn quick.  For example, when I started learning Primefaces, I made a custom drag and drop interface in a week.  Ask another developer how hard that is. I have seen what does not work – My varied experience is a benefit here.  I have seen what does and does not work.  One may not be doing it the best way possible.  Ask me during the interview how I would do things given the situation.  I will answer a few questions like that but unless I volunteer, one is coming closer to “pay for it” territory. I am cheaper than one thinks – Sure I am asking for a lot but I have never been in a job where software development was my only thing to do.  I have stood up and maintained continuous integration, bug tracking, wiki and software repository servers.  Start doing the math and I am getting to be pretty cheap. I have passion – I love software development.  I like learning the “problem space” and developing a solution to the problem.  I am so eager to learn that I will try different technologies to see what works.  No, I do not have ten years in Java EE, that is because I was fulfilling requirements in the best way possible.Moral of the Story In the end, I decided to take a job with another government contractor.  Everything about the job felt right.  However, if one is looking for a Java developer and finds a resume that has a lot of different technologies but not enough of one to meet your experience requirements, do not dump it.  Give him or her a call.  That might be the one that fits the position better than one hoped.Reference: What Happens When a Contractor Wants to Go Full time from our JCG partner Daryl Mathison at the Daryl Mathison’s Java Blog blog....

The dreaded DefaultAbstractHelperImpl

A while ago, we have published this fun game we like to call Spring API Bingo. It is a tribute and flattery to Spring’s immense creativeness when forming meaningful class names likeFactoryAdvisorAdapterHandlerLoader ContainerPreTranslatorInfoDisposable BeanFactoryDestinationResolver LocalPersistenceManagerFactoryBeanTwo of the above classes actually exist. Can you spot them? If no, play Spring API Bingo! Clearly, the Spring API suffers from having… To name things There are only two hard problems in computer science. Cache invalidation, naming things, and off-by-one errors – Tim Bray quoting Phil Karlton There are a couple of these prefixes or suffixes that are just hard to get rid of in Java software. Consider this recent discussion on Twitter, that inevitably lead to an (very) interesting discussion: Having Interface: PaymentService Implementation: PaymentServiceImpl The test should be called PaymentServiceImplTest not PaymentServiceTest — Tom Bujok (@tombujok) October 8, 2014Yes, the Impl suffix is an interesting topic. Why do we have it, and why do we keep naming things that way? Specification vs. body Java is a quirky language. At the time it was invented, object orientation was a hot topic. But procedural languages had interesting features as well. One very interesting language at the time was Ada (and also PL/SQL, which was largely derived from Ada). Ada (like PL/SQL) reasonably organises procedures and functions in packages, which come in two flavours: specification and body. From the wikipedia example: -- Specification package Example is procedure Print_and_Increment (j: in out Number); end Example;-- Body package body Example is procedure Print_and_Increment (j: in out Number) is begin -- [...] end Print_and_Increment; begin -- [...] end Example; You always have to do this, and the two things are named exactly the same: Example. And they’re stored in two different files called Example.ads (ad for Ada and s for specification) and Example.adb (b for body). PL/SQL followed suit and names package files Example.pks and Example.pkb with pk for Package. Java went a different way mainly because of polymorphism and because of the way classes work:Classes are both specification AND body in one Interfaces cannot be named the same as their implementing classes (mostly, because there are many implementations, of course)In particular, classes can be a hybrid of spec-only, with a partial body (when they’re abstract), and full spec and body (when they’re concrete). How this translates to naming in Java Not everyone appreciates clean separation of specs and body, and this can certainly be debated. But when you’re in that Ada-esque mind set, then you probably want one interface for every class, at least wherever API is exposed. We’re doing the same for jOOQ, where we have established the following policy to name things: *Impl All implementations (bodies) that are in a 1:1 relationship with a corresponding interface are suffixed Impl. If ever possible, we try to keep those implementations package-private and thus sealed in the org.jooq.impl package. Examples are:Cursor and it corresponding CursorImpl DAO and it corresponding DAOImpl Record and it corresponding RecordImplThis strict naming scheme makes it immediately clear, which one is the interface (and thus public API), and which one is the implementation. We wish Java were more like Ada with this respect, but we have polymorphism, which is great, and… Abstract* … and it leads to reusing code in base classes. As we all know, common base classes should (almost) always be abstract. Simply because they’re most often incomplete implementations (bodies) of their corresponding specification. Thus, we have a lot of partial implementations that are also in a 1:1 relationship with a corresponding interface, and we prefix them with Abstract. Most often, these partial implementations are also package-private and sealed in the org.jooq.impl package. Examples are:Field and it corresponding AbstractField Query and it corresponding AbstractQuery ResultQuery and it corresponding AbstractResultQueryIn particular, ResultQuery is an interface that extends Query, and thus AbstractResultQuery is a partial implementation that extends the AbstractQuery, which is also a partial implementation. Having partial implementations makes perfect sense in our API, because our API is an internal DSL (Domain-Specific Language) and thus has thousands of methods that are always the same, no matter what the concrete Field really does – e.g. Substring Default* We do everything API related with interfaces. This has proven highly effective already in popular Java SE APIs, such as:Collections Streams JDBC DOMWe also do everything SPI (Service Provider Interface) related with interfaces. There is one essential difference between APIs and SPIs in terms of API evolution:APIs are consumed by users, hardly implemented SPIs are implemented by users, hardly consumedIf you’re not developing the JDK (and thus don’t have completely mad backwards-compatibility rules), you’re probably mostly safe adding new methods to API interfaces. In fact, we do so in every minor release as we do not expect anyone to implement our DSL (who’d want to implement Field‘s 286 methods, or DSL‘s 677 methods. That’s mad!) But SPIs are different. Whenever you provide your user with SPIs, such as anything suffixed *Listener or *Provider, you can’t just simply add new methods to them – at least not prior to Java 8, as that would break implementations, and there are many of them. Well. We still do it, because we don’t have those JDK backwards-compatibility rules. We have more relaxed ones. But we suggest our users do not implement the interfaces directly themselves, but extend a Default implementation instead, which is empty. For instance ExecuteListener and the corresponding DefaultExecuteListener: public interface ExecuteListener { void start(ExecuteContext ctx); void renderStart(ExecuteContext ctx); // [...] }public class DefaultExecuteListener implements ExecuteListener {@Override public void start(ExecuteContext ctx) {}@Override public void renderStart(ExecuteContext ctx) {}// [...] } So, Default* is a prefix that is commonly used to provide a single public implementation that API consumers can use and instantiate, or SPI implementors can extend – without risking backwards-compatibility issues. It’s pretty much a workaround for Java 6 / 7’s lack of interface default methods, which is why the prefix naming is even more appropriate. Java 8 Version of this rule In fact, this practice makes it evident that a “good” rule to specify Java-8 compatible SPIs is to use interfaces and to make all methods default with an empty body. If jOOQ didn’t support Java 6, we’d probably specify our ExecuteListener like this: public interface ExecuteListener { default void start(ExecuteContext ctx) {} default void renderStart(ExecuteContext ctx) {} // [...] } *Utils or *Helper OK, so here’s one for the mock/testing/coverage experts and aficionados out there. It’s TOTALLY OK to have a “dump” for all sorts of static utility methods. I mean, of course you could be a member of the object-orientation police. But… Please. Don’t be “that guy”! So, there are various techniques of identifying utility classes. Ideally, you take a naming convention and then stick to it. E.g. *Utils. From our perspective, ideally you’d even just dump all utility methods that are not stricly bound to a very specific domain in a single class, because frankly, when did you last appreciate having to go through millions of classes to find that utility method? Never. We have org.jooq.impl.Utils. Why? Because it’ll allow you to do: import static org.jooq.impl.Utils.*; This then almost feels as if you had something like “top-level functions” throughout your application. “global” functions. Which we think is a nice thing. And we totally don’t buy the “we can’t mock this” argument, so don’t even try starting a discussion Discussion … or, in fact, let’s do start a discussion. What are your techniques, and why? Here are a couple of reactions to Tom Bujok’s original Tweet, to help get you started: @tombujok No. PaymentServiceImplTestImpl! — Konrad Malawski (@ktosopl) October 8, 2014@tombujok get rid of the interface — Simon Martinelli (@simas_ch) October 8, 2014@tombujok Impl everything! — Bartosz Majsak (@majson) October 8, 2014@tombujok @lukaseder @ktosopl root cause is the class should *not* be called *Impl, but I know you were trolling us all the time anyway — Peter Kofler (@codecopkofler) October 9, 2014Let’s go !Reference: The dreaded DefaultAbstractHelperImpl from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog....

Poking around your REST application with a scriptable endpoint

I love the fact that JDK comes with a ScriptEngine. It’s so flexible when you want to evaluate and troubleshoot your application that’s already deployed in an server environment. Add this REST endpoint into a Java EE app, and it will give you instant access to internal states of the app.             package myrestapp;import java.io.StringReader; import java.util.logging.Logger; import javax.script.Bindings; import javax.script.ScriptEngine; import javax.script.ScriptEngineManager; import javax.servlet.ServletContext; import javax.servlet.http.HttpServletRequest; import javax.ws.rs.POST; import javax.ws.rs.Path; import javax.ws.rs.core.Context;/** * Give instant access to your internal application with dynamic scripting. * * <p>Example script: * <pre> * "sc" + servletContext + ", req=" + request; * </pre> * * <p>Example2 * <pre> * names = servletContext.getAttributeNames(); * while(names.hasMoreElements()) { * name = names.nextElement(); * println(name); * } * </pre> */ @Path("script") public class ScriptResource { private static final Logger logger = Logger.getLogger(ScriptResource.class.getName()); @Context private ServletContext servletContext; @POST public String script(@Context HttpServletRequest request, String scriptText) throws Exception { String engineName = "JavaScript"; ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine engine = manager.getEngineByName(engineName); logger.info("Running script text length=" + scriptText.length() + ", engine=" + engine); Object result = null; try (StringReader reader = new StringReader(scriptText)) { Bindings bindings = engine.createBindings(); bindings.put("servletContext", servletContext); bindings.put("request", request); result = engine.eval(reader, bindings); } logger.info("Result " + result); return "" + result; } } Notice that I gave couple JavaScript examples in the comment area already. You will have access to two binding variables that should give you full access to many internal components of your application. Need an UI to test out this endpoint? How about give the “Advance Rest Client” Chrome Extension a try? (Thanks to my co-worker’s Chris Griffin tips on this cool extension. It’s really handy tool to have!).Reference: Poking around your REST application with a scriptable endpoint from our JCG partner Zemian Deng at the A Programmer’s Journal blog....

AssertJ > Fest > Hamcrest

I have previously blogged about Hamcrest, and using its assertThat methods in preference to JUnit’s Assert. However, I quickly after discovered FEST Assertions, and happily switched to it. It provides the same improved test readability and improves failure messages as Hamcrest, but has the extra benefit of enabling IDE auto completion, rather than having to search through package and class docs to find the right matcher. Unfortunately, Fest seems to not longer be actively developed. The last stable release of the 1.x branch, 1.4, was released way back in 2011, and the new 2.x branch never made it to a stable release and hasn’t had a commit since June 2013. Enter AssertJ… Assert J AssertJ is a fork of Fest Assert, and seems to provide all the benefits plus a bunch of new features. Collections For example, it has all the nifty collections handling I so liked from Fest: List<String> stringList = Lists.newArrayList("A", "B", "C"); assertThat(stringList).contains("A"); //true assertThat(stringList).doesNotContain("D"); //true assertThat(stringList).containsOnly("A"); //false assertThat(stringList).containsExactly("A", "C", "B"); //false assertThat(stringList).containsExactly("A", "B", "C"); //true Collect all errors before failing It also has the ability to catch all failures before failing. For example, the above eample would fail as the first failed assumpion. The below example allows you to see all failed assertions: List<String> stringList = Lists.newArrayList("A", "B", "C"); SoftAssertions softly = new SoftAssertions(); softly.assertThat(stringList).contains("A"); //true softly.assertThat(stringList).containsOnly("A"); //false softly.assertThat(stringList).containsExactly("A", "C", "B"); //false softly.assertThat(stringList).containsExactly("A", "B", "C"); //true // Don't forget to call SoftAssertions global verification! softly.assertAll(); And results in a message like this: The following 2 assertions failed: 1) Expecting: <["A", "B", "C"]> to contain only: <["A"]> elements not found: <[]> and elements not expected: <["B", "C"]> 2) Actual and expected have the same elements but not in the same order, at index 1 actual element was: <"B"> whereas expected element was: <"C"> Definitely worth a look. AssertJ core code and issue tracker are hosted on github.Reference: AssertJ > Fest > Hamcrest from our JCG partner Shaun Abram at the Shaun Abram’s blog blog....

Legacy Code to Testable Code #3: Adding Setter Accessors

This post is part of the “Legacy Code to Testable Code” series. In the series we’ll talk about making refactoring steps before writing tests for legacy code, and how they make our life easier. Adding accessors to private state data is an admission that either our design is wrong, or that we’re adding the accessors purely for testing. If that state was private before, how come are we exposing it? And if so, maybe tests are not the only clients of this data. We need an accessor in two cases:When we need to inject values that are otherwise hard to inject When we need to probe the internal state to understand the impact of our operationIn both cases, we’re adding functions that were not needed before. Meaning, the caller did not need to either inject or probe the data. Now our tests, another client, demand an additional entry point. In this post, I’ll concentrate on the Set accessors for injecting values. Injecting values If we have other methods, we might not need an accessor. For example, we have a private field that’s initialized in the constructor: public Account(Bank bank) { this.bank = bank; ... If we pass the new bank value as a parameter, we can set it in our tests easily to whatever we need. However, if the constructor looks like this: public Account() { this.bank = new Bank(); ... The seam for inserting our bank is no longer there, and we need another way to inject it. In another case, the new bank can come from an external source: public Account() { this.bank = BankFactory.getBank(); ... In both of these cases, we can mock the creation or the static call with power tools. If we can’t use those, we can introduce a “setter” method. This “setter” can be public or at least accessible to our test. public setBank(Bank bank) { this.bank = bank; } When we call this method, it overrides the value that the constructor initialized. This doesn’t work if our constructor already did something with the original value. Usually it’s not a problem, because we’re testing code in another method, so whatever the constructor did, the tested method will be under our influence. In other cases, we can mock the constructor using partial-mocking for eliminating code that runs in the constructor, or use power tools to mock the factory method. From here it gets complicated. What if our `bank` is static? Consider a private static singleton: private static Bank theBank = new Bank(): Once initialized, it cannot be replaced through regular means. If our test calls for it, replacing it can be easier by injecting our own mockBank. So we can add a static “setter”: public static void setBank(Bank bank) { theBank = bank; } As before adding an external “setter” is a risk: What if someone else decides to call it? We can reduce accessibility, but the risk is still there. In both former cases, we could store the overriding mockBank. It maybe that the value is not stored anywhere, only created on the stack, in the tested method: public void getAccount() { Bank tempBank = new Bank(); ... Here, we cannot access tempBank, because it’s on the stack. In this case, we can do a bit of refactoring in order to allow injection. We’ll first extract the creation into a private method called getBank: private Bank getBank() { return new Bank(); } public void getAccount() { Bank tempBank = getBank(); ... Using refactoring tools, we can reuse this method for every creation. We can then introduce a field and a “setter”, and modify the getAccount method: private Bank bank = Null; public void setBank(Bank bank) { this.bank = bank; } private Bank getBank() { if (this.bank == Null) return new Bank(); else return this.bank; } Using this method we skip mocking (and reduce coupling) at the expense of design changes. We can’t escape trade-offs. There’s a final option for injecting values, if the language supports it: Reflection.  If we use reflection in the test, there is no need for modification in the tested code. However, tests using reflection are as fragile as mocking tests, sometime even more so. Reflection access is fragile, and not refactorable. Therefore, this method should be considered last in the solutions offered. That’s it for now. Next time we’ll continue the discussion about accessors with “getters”.Reference: Legacy Code to Testable Code #3: Adding Setter Accessors from our JCG partner Gil Zilberfeld at the Geek Out of Water blog....

Data as a Service: JBoss Data Virtualization and Hadoop powering your Big Data solutions

Red Hat and Cloudera, announce the formation of a strategic alliance. From JBoss perspective, the key objective of the alliance is to leverage big data enterprise-wide and not let Hadoop become another data silo. Cloudera combined with Red Hat JBoss Data Virtualization integrates Hadoop with existing information sources including data warehouses, SQL and NoSQL databases, enterprise and cloud applications, and flat and XML files. The solution creates business-friendly, reusable and virtual data models with unified views by combining and transforming data from multiple sources including Hadoop. This creates integrated data available on-demand for external applications through standard SQL and web services interfaces. The reality at vast majority of organization is that data is spread across too many applications and systems. Most organizations don’t know what they’ve lost because their data is fragmented across the organization. This problem does not go away just because an organization is using big data technology like Hadoop; in fact, they get more complicated. Some organizations try to solve this problem by hard coding the access to data stores. This simple approach inefficiently breaks down silos and brings lock-in with it. Lock-in makes applications less portable, a key metric for future proofing IT. This approach also impedes organizational agility because hard coding data store access is time consuming and makes IT more complex, incurring technical debt. Successful business need to break down the data silos and make data accessible to all the applications and stakeholders (often a requirement for real time contextual services).A much better approach to solving this problem is abstraction through data virtualization. It is a powerful tool, well suited for the loose coupling approach prescribed by the Modern Enterprise Model. Data virtualization helps applications retrieve and manipulate data without needing to know technical details about each data store. When implemented, organizational data can be easily accessed using a simple REST API or via familiar SQL interface. Data Virtualization (or an abstracted Data as a Service) plugs into the Modern Enterprise Platform as a higher-order layer, offering the following advantages:Better business decisions due to organization wide accessibility of all data Higher organizational agility Loosely coupled services making future proofing easier Lower costData virtualization is therefore a critical part of the big data solution. It facilitates and improves the use of big data in the enterprise by:Abstracting big data into relational-like views Integration with existing enterprise sources Adding real time query capabilities to big data Providing full support for standard based interfaces like REST and OData in addition JDBC and ODBC. Adding security and governance to the big data infrastructure Flattening data siloes through a unified data layer.If you want to learn more, download, and get started with JBoss Data Virtualization, then visit: http://www.jboss.org/products/datavirt Data Virtualization by Example: https://github.com/datavirtualizationbyexample If you’re interested in community version, then visit: http://teiid.jboss.org/Reference: Data as a Service: JBoss Data Virtualization and Hadoop powering your Big Data solutions from our JCG partner Arun Gupta at the Miles to go 2.0 … blog....

Beginner’s Guide to Hazelcast Part 4

This is the fourth installment of my Hazelcast series. If one has not seen the other 3, I suggest one go to Part 1, Part 2 and Part 3. Logging Logging is an important feature of any application and my examples are no different. System.out.println can be a useful tool for telling the user what is going on in console applications. But let’s face it, if one is reading how to use a tool for distributed applications, that person is really not a beginner. Seeing a series of logging messages should not scare anyone. In fact, for the examples in this post, they are necessary to know what is going on by whom. We will be talking about threaded programming after all. The good folks at Hazelcast seem to have agreed that logging is important and so have many different ways to define what library is logging. The logging framework only depends on JDK logging and has a number of adapters that even allow for custom logging frameworks. One’s logging adapter of choice is set by the property, hazelcast.logging.type to the following settings:JDK logging, This is the default. log4j slf4j noneI used Log4j2 so I picked slf4j and put in the four jar files needed to get it working. Spinning Distributed Threads Like many classes in Hazelcast, IExecutorService implements an interface from Java’s libraries, the ExecutorService. This interface defines what it is to be a thread pool. The interface is part of the java.util.concurrent package and has been around since Java 1.5. The package also has implementations of it one can access from java.util.concurrent.Executors. I wish I had something like this in Java 1.4 or 1.3 or 1.2 or 1.1. Making thread pools were fun until deadlocks happened. Now I can use Java library’s pools, good enough for me. ExecutorServices have an interesting “feature.” One must shut them down or the service will not go away. The first time I used them, I caused a memory leak and shutdown the JVM. I caught the bug during my own testing so the customer never had to see my learning experience. IExecutorService has a different wrinkle. The service will not go away until all the threads finish. This caused many unclean shutdowns. You have been warned! IExecutorServices can share out threads several different ways. Here they are in detail: Any ‘Ole Instance This is when one calls just the submit(Callable call).  This does more than just set a thread randomly into the cluster.  It does some load balancing with that thread so an instance does not get clobbered with threads. To a Particular Member This is done via the submit(Callable call, Member member) method.  This sends a thread to a particular member of the cluster.   No load balancing here; just sending to a member.  Be careful, one can easily overload a member and really put the brakes on any processing being done.  I could see this as a way to create a custom load balancer. To a Collection of Members Yeah, one can send a thread to multiple members.  When i was doing my example coding, the members all act like they got their own thread and are not sharing one.  If one implements Callable<T> as their thread implementation, the method returns a Map of Futures using the members as the key.  If one uses Runnable, it returns nothing. To The Member With the Right Key Entries to a IMap can be anywhere on the cluster. If processing is needed to be done on that entry, a local thread would have to pull up the entry over the network. This can be a problem if the entry is very large. A better way would be to transfer the hopefully smaller thread over to the entry. To do that, the cluster needs to know where to send it. Hence, the call submit(Callable call, Object key). To All Members This works the same way as submitting to a collection of members but it is all of them, as in every member in the cluster.  This could get “fun” if one has a large number of members in a cluster.  I think I have heard as much as a 1000 members in one cluster.  Make sure this is what one wants before it is called. Using an ExecutionCallback This is basically a way to send out some threads and let the results come back asynchronously.  One uses an ExecutionCallback if one thread is submitted.  One uses MultiExecutionCallback if more than one member is involved. Example Code Before I start, let me say that I do not have an example for every method in IExecutorService.  I do have an example for every type discussed, however.  Another thing about the example code.  For instructional purposes I have done some copy-and-paste coding in prior posts so each example can stand on its own and one can get a context of what goes where.  I did this quite a bit in part 3.  If one did not notice it, look at it again. This time I did not do it because there would have been a lot of code copied and the results would have been pretty ugly.  I used an Enum and I think the results were very good.  I thought an Enum was a good choice because of the limited number of examples and allowed me to be able to show the code in chunks that are understandable if the framework was shown first. With that explanation, lets move on! Framework This are the main bits. It consists of the main class and the thread class.  Notice how the main class shows each way a thread can submitted being called. Main package hazelcastservice;import com.hazelcast.core.Hazelcast; import com.hazelcast.core.HazelcastInstance; import com.hazelcast.core.IExecutorService; import java.util.ArrayList; import java.util.List; import java.util.concurrent.ExecutionException; import java.util.concurrent.RejectedExecutionException; import org.slf4j.Logger; import org.slf4j.LoggerFactory;/** * * @author Daryl */ public class Main { private static final Logger logger = LoggerFactory.getLogger(Main.class); public static final String SERVICE_NAME = "spinnerella"; public static final int NUM_INSTANCES = 5; /** * @param args the command line arguments */ public static void main(String[] args) { System.setProperty("hazelcast.logging.type", "slf4j"); List<HazelcastInstance> instances = new ArrayList<>(NUM_INSTANCES); for(int i = 0; i < NUM_INSTANCES; i++) { instances.add(Hazelcast.newHazelcastInstance()); logger.info("instance {} up", i); }IExecutorService spinner = instances.get(0).getExecutorService(SERVICE_NAME); try { HazelcastIExecutorServiceExamples.TO_SOME_MEMBER.example(instances, spinner); HazelcastIExecutorServiceExamples.TO_PARTICULAR_MEMBER.example(instances, spinner); HazelcastIExecutorServiceExamples.ON_THE_KEY_OWNER.example(instances, spinner); HazelcastIExecutorServiceExamples.ON_A_SET_OF_MEMBERS.example(instances, spinner); HazelcastIExecutorServiceExamples.ON_ALL_MEMBERS.example(instances, spinner); HazelcastIExecutorServiceExamples.CALLBACK.example(instances, spinner); HazelcastIExecutorServiceExamples.MULTIPLE_MEMBERS_WITH_CALLBACK.example(instances, spinner); //Lets setup a loop to make sure they are all done (Especially the callback ones) for(HazelcastIExecutorServiceExamples example: HazelcastIExecutorServiceExamples.values()) { while(!example.isDone()) { Thread.sleep(1000); } } } catch(ExecutionException ee) { logger.warn("Can't finish the job", ee); } catch(InterruptedException ie) { logger.warn("Everybody out of the pool", ie); } finally { // time to clean up my toys boolean allClear = false; while(!allClear) { try { Thread.sleep(1000); Hazelcast.shutdownAll(); allClear = true; } catch(InterruptedException ie) { //got interrupted. try again } catch(RejectedExecutionException ree) { logger.debug("caught a RejectedExecutionException"); allClear = false; } } logger.info("All done"); } } } Thread package hazelcastservice;import java.io.Serializable; import java.util.Random; import java.util.concurrent.Callable; import org.slf4j.Logger; import org.slf4j.LoggerFactory;/** * This class was inspired by the song "I Like to Move it" from the movie * Madagascar by Dreamworks. I offer NO apologies for using it. * * To those software developers who like consistent results, I used java.util.Random to * make it loop inconsistently each time call is called. * * Sometimes you need to make your own entertainment. * @author Daryl */ public class MoveItMoveIt implements Callable<Integer>, Serializable { private static final Logger logger = LoggerFactory.getLogger(MoveItMoveIt.class); private static final int UPPER_BOUND = 15; @Override public Integer call() throws Exception { Random random = new Random(); int howMany = random.nextInt(UPPER_BOUND); // int howMany = 2; for(int i = 0; i < howMany; i++) { logger.info("I like to Move it Move it!"); } logger.info("Move it!"); return howMany; } } The Particulars Here I go showing the different types of calls that were discussed. Remember that these are chunks of an Enum class. The done is a protected variable and the public void example(List<HazelcastInstance> instances, IExecutorService spinner) needed to implemented. Any ‘Ole Instance TO_SOME_MEMBER() { @Override public void example(List<HazelcastInstance> instances, IExecutorService spinner) throws ExecutionException, InterruptedException { logger.info("Submit to some member."); Future<Integer> howMany = spinner.submit(new MoveItMoveIt()); logger.info("It moved it {} times", howMany.get()); done = true; } } To a Particular Member TO_PARTICULAR_MEMBER { @Override public void example(List<HazelcastInstance> instances, IExecutorService spinner) throws ExecutionException, InterruptedException { logger.info("Submit to a particular member."); Member member = getRandomMember(instances); logger.debug("member is {}", member); Future<Integer> howMany = spinner.submitToMember(new MoveItMoveIt(), member); logger.info("It moved it {} times.", howMany.get()); done = true; } private Member getRandomMember(List<HazelcastInstance> instances) { Set<Member> members = instances.get(0).getCluster().getMembers(); int i = 0; int max = new Random().nextInt(instances.size()); Iterator<Member> iterator = members.iterator(); Member member = iterator.next(); while(iterator.hasNext() && (i < max)) { member = iterator.next(); i++; } return member; } } To a Collection of Members ON_A_SET_OF_MEMBERS { @Override public void example(List<HazelcastInstance> instances, IExecutorService spinner) throws ExecutionException, InterruptedException { logger.info("Send to some of the members"); Set<Member> randomMembers = getRandomMembers(instances); Map<Member, Future<Integer>> results = spinner.submitToMembers(new MoveItMoveIt(), randomMembers); for(Future<Integer> howMany: results.values()) { logger.info("It moved {} times", howMany.get()); } done = true; } private Set<Member> getRandomMembers(List<HazelcastInstance> instances) { int max = new Random().nextInt(instances.size()); Set<Member> newSet = new HashSet<>(instances.size()); int k = 0; Iterator<Member> i = instances.get(0).getCluster().getMembers().iterator(); while(i.hasNext() && k < max) { newSet.add(i.next()); k++; } return newSet; } } To The Member With the Right Key ON_THE_KEY_OWNER { @Override public void example(List<HazelcastInstance> instances, IExecutorService spinner) throws ExecutionException, InterruptedException { logger.info("Send to the one owning the key"); HazelcastInstance randomInstance = getRandomInstance(instances); IMap<Long, Boolean> map = randomInstance.getMap("default"); Long one = 1L; map.put(one, Boolean.TRUE); Future<Integer> howMany = spinner.submitToKeyOwner(new MoveItMoveIt(), one); logger.info("It moved it {} times.", howMany.get()); done = true; } private HazelcastInstance getRandomInstance(List<HazelcastInstance> instances) { return instances.get(new Random().nextInt(instances.size())); }} To All Members ON_ALL_MEMBERS { @Override public void example(List<HazelcastInstance> instances, IExecutorService spinner) throws ExecutionException, InterruptedException { logger.info("Send to all members"); Map<Member, Future<Integer>> results = spinner.submitToAllMembers(new MoveItMoveIt()); for(Future<Integer> howMany: results.values()) { logger.info("It moved {} times", howMany.get()); } done = true; } } Using an ExecutionCallback This example code contains two chunks of code to show a single callback and a multiple callback. CALLBACK { @Override public void example(List<HazelcastInstance> instances, IExecutorService spinner) throws ExecutionException, InterruptedException { logger.info("example with a callback"); spinner.submit(new MoveItMoveIt(), new ExecutionCallback<Integer>() { @Override public void onResponse(Integer response) { logger.info("It moved {} times", response); done = true; }@Override public void onFailure(Throwable thrwbl) { logger.error("trouble in the callback", thrwbl); done = true; } }); } }, MULTIPLE_MEMBERS_WITH_CALLBACK { @Override public void example(List<HazelcastInstance> instances, IExecutorService spinner) throws ExecutionException, InterruptedException { logger.info("running on multiple members with callback"); spinner.submitToAllMembers(new MoveItMoveIt(), new MultiExecutionCallback() {@Override public void onResponse(Member member, Object o) { logger.info("member finished with {} moves", o); }@Override public void onComplete(Map<Member, Object> map) { logger.info("All members completed"); for(Object value: map.values()) { logger.info("It moved {} times", value); } done = true; } }); } Conclusion It was good to publish my own code/ideas again on my blog. I took a quick look at the power of the IExecutorService by Hazelcast. My example code followed the DRY principle. The code in its entirety can be found here. References As always with my Hazelcast guides, my information comes from Hazelcast documentation that can be found at here.Reference: Beginner’s Guide to Hazelcast Part 4 from our JCG partner Daryl Mathison at the Daryl Mathison’s Java Blog blog....
Java Code Geeks and all content copyright © 2010-2014, 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 two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below: