Posts tagged "Java"

When you’re writing Java applications, chances are you’re using Maven for dependency management. It lets you declare the artifacts you need to build your application. Those artifacts also depend on other artifacts. This means you have transitive dependencies - dependencies you didn’t declare yourself but you need them anyway.

From yesterday until tomorrow I’m attending Devoxx Poland (or Devoxx PL for short). It’s the second largest conference in the Devoxx family with around 2700 people attending. The conference is held in the ICE Kraków Congress Centre, a large venue with an amazing primary room.

The main reason I’m here is to give a talk about GraalVM on Wednesday morning. Apart from that, it’s a nice opportunity to network, meet old friends and make new ones. And of course to attend other talks to learn something new.

Recently, Twitter brought the renaming of Ozark to Krazo to my attention. It pulled my attention: I had never heard of either projects, and I wondered what they would be about. Ozark (or Krazo) will be the Reference Implementation of the new Model-View-Controller Specification. This MVC specification, also known as JSR 371, was planned for inclusion in Java EE 8, but eventually dropped. Apparently, this didn’t kill the effort. I was curious to see where the specification (and it’s implementation) would be now.

There are many situations when you need to write a SOAP-based webservice. Maybe you are writing a test dummy, or maybe you got the interface from some kind of architect. (Yes, there are other reasons, too.) And chances are you’ll be using Spring-WS to do this.

Recently I was doing that, and I found the following inside the interface definition (WSDL):

<element name="faultMessage" type="common:FaultMessage"/>

<message name="faultMessage">
    <part name="faultMessage" element="tns:faultMessage"/>
</message>

<portType name="someName">
    <operation name="searchOrder">
        <input message="tns:searchOrderRequest"/>
        <output message="tns:searchOrderResponse"/>
        <fault name="faultMessage" message="tns:faultMessage"/>
    </operation>
</portType>

That was a rather challenging thing! In case the operation would fail, it should give a SOAP Fault with a custom element in it:

Last Tuesday was the first edition of JVMCON. This conference has a special programme committee: its audience. When the Call for Papers closed, everyone who had a ticket could see the submitted papers. Only, they could not see who submitted the paper - which let them focus on the papers themselves. Out of almost 180 papers, they had to select 13…

And guess what: one of them was mine! I presented my talk for the early birds, and there were quite a lot of them! The room was pretty much packed, and there was a lot of questions and remarks afterwards. That surprised me a bit, since I usually do not experience a lot of interaction with the audience.

A few weeks ago, I wrote about migrating an existing Spring-application to Java 9. When I finished, two things remained to be investigated:

1. Code coverage for unit tests.
2. A bunch of warnings when running the application in Tomcat.

Code coverage for unit tests

As Alan Bateman pointed out, upgrading JaCoCo to its latest version should resolve the issue about the $jacocoData field. In fact, I thought I had done that, but somehow I kept on getting the same error every single time. But when I tried (again) last week, it somehow disappeared. No error to be seen, all tests green, and a nice coverage report from JaCoCo. I’m a happy developer, again!