Irwan Hendra's Random Codes Blog

Introduction Few people have heard of JMH, yet if harnessed properly, can be a very valuable tool, typically when we come across performance considerations. Now and then we will come across a task that can be done multiple different ways but we are unsure which one is the best performing code. A quick JMH code over Java command line application can quickly tell you how is one code performing compared to the other. What JMH does when properly coded is to take your piece of code and run it for multiple warm up iterations to clear the memory cache, and then run it again over X amount iterations to obtain the averaged benchmark result. Elaboration Using JMH It is recommended to use JMH in the most simplest java way, ie using the old and standard public static void main: public static void main (String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(JmhTestRun. class .getSimpleName()) .forks( 1 ) .build() ; new Runner(opt).run...

Spring Framework provides a very handy Http connection class specialized on REST communication named RestTemplate. The RestTemplate has a wealth of REST call methods that can be easily used to quickly invoke external / remote REST API endpoints with no mess of opening and closing sockets, or even marshal and unmarshaling java objects. However such ease of use comes with a caveat, whenever we need greater control with the connection, or the marshal and unmarshal process of java objects we can't do so easily as when we are using HttpConnection class. Nevertheless, one way we can gain some control to the Request and Response is through ClientHttpRequestInterceptor interface. When registered to the RestTemplate object, this interface grants us access to the Request object, request body data and also Response object. The example below shows how we can utilize ClientHttpRequestInterceptor interface to log Request and Response during a typical communication with external API: im...

Mocking JNDI calls for Unit Test Sometimes, on the rarer cases the properties data that usually drive a server based application resides in the JNDI calls instead of something.properties file. In such scenario, mocking the JNDI calls using Mockito or Powermock are inherently difficult. Luckily the Spring Framework provides a way to "mock" the context by using SimpleNamngContextBuilder. By declaring the JNDI calls in a static method (because the Builder needs to be activated before any other autowiring could take place): @BeforeClass     public static void oneTimeSetUp() throws Exception {         SimpleNamingContextBuilder builder = new SimpleNamingContextBuilder();                 builder.bind("sampleJndiKey", "sampleJndiiValue");         builder.activate();     } Here's a full sample: @RunWith(SpringJUnit4ClassRunner.class) @WebAppConfiguration @ContextConfigur...

Sniffing Request and Response on Wiremock Often we use Wiremock on our test classes without knowing how the entire request or response looks like, well, mostly the requests since we can construct the response body from plain string. For that apparently Wiremock has a nice little request listener that can be utilised to print out all requests received by the Wiremock port: Syntax:   @Rule   WireMockRule wmr = new WireMockRule(8888);   @Before   public void setUp() {     wmr.addMockServiceRequestListener(new RequestListener() {       @Override       public void requestReceived(Request req, Response resp) {         System.out.println("URL: " + req.getAbsoluteUrl());         System.out.println("Req Body: " + req.getBodyAsString());         System.out.println("Resp Code: " + resp.getStatus());         System.out.pr...