Pages

Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Wednesday, May 18, 2016

Hello World with JBoss Modules


JBoss Modules is quite an interesting project that powers JBoss application server and some other projects in JBoss ecosystem. However, I was surprised to find out that there isn't much you can find about Modules on the webs. Documentation is... bad half-done, not that many tutorials, no good examples of how you could use this awesome library in your project. The best you can find is the description on how to apply JBoss Modules within the application server. (sad panda)

I was looking for the simplest "Hello World" example and couldn't find it. Well, why not create one myself then? 


Downloading JBoss Modules

A surprising fact is that you won't find JBoss Modules in the list of upstream projects at jboss.orgThe first option is to download the jboss-modules.jar from Bintray or Maven Central. And the second option is to build it from sources

Oh, ok, one more option (not the best one) is to download the application server that includes jboss-modules.jar, e.g. WildFly.


Hello World

Ahh, the good old "Hello World" :) The main application class is as follows:

public class Main {
  public static void main(String[] args) {
     new Hello().say();
  }
}

So we have a dependency, the Hello class, that will reside in a different module:

public class Hello {
  public void say(){
    System.out.println("Hello!");
  }
}

So to mimic the modules we first have to compile both classes and assemble corresponding JARs. Plus, a proper directory layout is expected by JBoss Modules to resolve the artefacts.


Main class belongs to 'app' module, and Hello class belongs to 'hello' module. Each module requires module.xml descriptor. This part is somewhat documented actually. Also the 'main' directory that you see within each module's directory structure is actually a version (!). 
A version slot identifier is an arbitrary string; thus one can use just about any system they wish for organization.  If not otherwise specified, the version slot identifier defaults to "main".
Here's the module.xml for the app module:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.5" name="app">
  <main-class name="Main"/>

  <resources>
    <resource-root path="main.jar"/>
  </resources>

  <dependencies>
        <module name="hello"/>
  </dependencies>
</module>

It specifies the main class (i.e. Main), the reference to the actual JAR that will be used in this module's classpath, and a dependency - the 'hello' module.

Same module.xml for the 'hello' module:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.5" name="hello">
  <resources>
    <resource-root path="hello.jar"/>
  </resources>
</module>

Voila! Now we can execute our brand new modular "Hello World" app:

> java -jar jboss-modules-1.5.1.Final.jar -mp mods app
Hello! 

The format for the command is as follows. First, java -jar jboss-modules.jar is used to bootstrap the environment; -mp mods, and the 'app' parameter is the name of the application module that should be executed.

This example isn't really practical, but at least it gives a hint on how to get started with JBoss Modules. Hopefully, one day, the documentation for this awesome project will be complete and there will be a bit more tutorials for different the use cases.



Friday, February 12, 2016

HotSwap vs hot deploy

It is the year 2016 and one still has to explain that HotSwap and hot deploy in Java IDEs is not the same thing.


Stackoverflow is full of questions about avoiding restarts of Java applications. So of the answers suggests that “Eclipse can update code without restarting the application” or “IntelliJ IDEA can hot update running applications” or “NetBeans automatically updates running code in debugger”. But the ultimate solution for this problem is JRebel, of course.

UPD: You can also read about various solutions to the redeployment problem in my Stackoverflow answer.

One fundamental thing that people don’t understand is that it is not even the capability of an IDE to be able to update applications. The IDE is just a medium -- it only triggers the update, and then the runtime environment is the one responsible for updating the code.

Repeat after me

HotSwap and Hot deploy is not the same thing!

What is HotSwap?

HotSwap (тм) is the technology in HotSpot JVM that is tailored at updating class definitions at runtime. Most importantly, "HotSwap adds functionality to the Java Platform Debugger Architecture (JPDA) to allow a class to be updated while under the control of a debugger”.

So when it comes to IDEs, once an application is started in a debug mode, the IDE can trigger class redefinition in a running JVM by utilizing JPDA.

If you are interested in the intimate details of HotSwap, read the “Safe class and data evolution in large and long-lived java applications” paper by M. Dmitriev.

It is important to understand the limitations of HotSwap: it is limited only to updating statements of code inside methods. Can’t change method signatures, can’t add new methods, fields, etc. Some JVM implementations are able to do a bit more. For instance, with IBM J9 JVM it is possible to add new methods to an existing class. Nevertheless, HotSwap capabilities are minimal. A JEP for enhanced class redefinition has been submitted long ago, and even a research project was sponsored by Oracle, but no further progress was made.

The bottom line here is that HotSwap is not a feature of an IDE, it is the ability of a JVM that you use.

What is hot deploy?

Hot deploy is the ability of application container to automatically deploy (web) applications at the startup. Obviously, the same feature can be applied to re-deploy the applications without restarting the JVM process.

Hot deploy is not a feature in any of the IDEs either. IDEs can only trigger (re)deployment of an application by either copying the artefacts to a correct location, or by using hooks if provided by the application server. So this is totally application server specific - this is what server adapters are for! It requires the IDE to be aware of the application server specifics, hence some people affiliate this functionality to their IDE.

Redeploying the application drops its state. Sometimes, application server can serialize/deserialize HTTP session state, but that's about it, not more. It can't preserve the state of the structures inside the application; internal caches have to be warmed up; framework internals have to be reinitialized, etc. The process is time consuming.

Application servers rely on class loader magic to redeploy applications. You can read about it in details in ZeroTurnaround’s blog.

Summary

Make sure you use the terms correctly -- 'HotSwap' and 'hot deploy' is not the same thing! You may other terms, like 'hot update' -- then make sure to ask, what does the person actually means by this, because the devil is in the details.

Thursday, December 10, 2015

Another great Java interview question: Singleton

I'm not a big fan to ask to write code at the interviews. But I still find it useful to do some coding exercises at the whiteboard. One of my favourites is the Singleton pattern. Because Singleton is so simple, you can use it as a starter for so many interesting discussions.

it often comes down to the discussions about the Singleton being lazy or eager. And while it leads to the discussion about Java Memory Model, it's not the most interesting one. No one understands Java Memory Model anyway :)

BTW, did you know that a single-element enum type is the best way to implement a Singleton?

Yes! And you can't imagine how many people do fail with this. If you deploy 2 web applications with the same Singleton class, will there be two instances of the same Singleton or one? Of course, there isn't one true answer for this question - you have to ask the details. The the answer depends much on how the class is loaded. If the class is packaged within the WARs, then you get 2 instances of the Singleton.



This is why Singleton is such a great interview question - it opens a lot of topics for further discussion!




Saturday, November 21, 2015

final/finally/finalize

I have been interviewing candidates for Java developer jobs for a full decade at this point. I have tried various approaches for the interviews: various tests about language and the APIs, whiteboard programming, bug hunting, homework assessments, etc. There is no best approach for the interviews - it merely depends on the expectations, candidate background, position, day of the week, weather, whatever else.

Despite all the details, I’ve found one interview question that works like a charm. It is almost the best question to start with. And it is quite efficient in filtering the candidates early enough if have to screen a lot of candidates.

Here’ it is:

What is the different between final, finally & finalize?

How is this even a question, you would ask? Asking about the difference of the things that cannot be compared!? Well, apparently, a lot of developers can't make a clear difference. Those who don’t - you just don’t have to interview them further :)

OK, you asked this and candidate answered this brilliantly, now what? Well, I did tell you that it is a very good question to start with, didn’t I? Next, you can take it to any direction of your choice:

  • final - you may take the discussion to Reflection API, for instance. Or you can discuss how the final keyword helps with concurrent programming in Java.
  • finally - talk more about the exceptions in Java and discuss some puzzles. Like the one below. What does it print?
  • finalize - the discussion about finalize() method is only useful to validate the nerd level of the candidate. Usually you’d check why one shouldn't use finalize() in first place. Maybe some rare candidate can tell about legitimate uses of finalize(). This most likely shows that he or she remembers what is written in Item 7 from Effective Java.

I hope you get my point now, why this strange question is a very good one for the Java interviews. Have fun!

Friday, July 10, 2015

GeekOut 2015: CompletableFuture

The talk by Tomasz Nurkiewicz about CompletableFuture was rated the highest at GeekOut this year. This is really interesting API that appeared in Java 8

A Future that may be explicitly completed (setting its value and status), and may be used as a CompletionStage, supporting dependent functions and actions that trigger upon its completion.

Tomasz Nurkiewicz - CompletableFuture in Java 8, asynchronous processing done right. from Official ZeroTurnaround Account on Vimeo.

Some time ago Tomasz published a really nice series of articles at his blog - worth reading!

Java 8: Definitive guide to CompletableFuture
Java 8: CompletableFuture in action

And there's more!

Sunday, April 5, 2015

Grails 3 Released. Setting up -javaagent

Grails 3 was released just recently and with all the new stuff it looks really-really-really awesome release! (Really hope that Grails will find the new home now). The two key changes for me are 1) moving to Gradle instead of Gant, and 2) building on top of Spring Boot. NOw it looks like it's basically the Gradle project with custom conventions that are derived from Grails 2.x.

For the first time, it feels like Grails is not a toy framework any more :)

What's not that cool (my own very subjective opinion), is the introduction of application.yml. It's almost impossible to modify it without reading the documentation. Even XML version of it (yes!) would have been more practical.

There are many other nice things added - go look for yourself.

Setting up a -javaagent argument for Grails 3

My personal interest with any new framework or server is usually related to the projects I'm working with. Thus, the first thing I wanted to check is how could I set up a -javaagent for Grails 3 application. Turns out, it's not as simple as you would expect.

Thanks to @bsideup, here's the snippet that you'd have to add to build.gradle file to setup a -javaagent argument, given that the agent JAR is located somewhere in file system:

In the example above, xrebel.jar is the agent package that is located somewhere in my file system. One can use the absolute path just fine in there.

Here's the another snippet, with DSL-style:

With this, I can confirm, that XRebel works with Grails 3 :)

Tuesday, March 24, 2015

IntelliJ IDEA 14.1 - Distraction Free Mode

IntelliJ IDEA 14.1 was released just recently with a good set of new features and improvements. Among other things, one really interesting feature that appeals to me is the new "distraction free mode".

Essentially, entering the distraction free mode means that you'd hide away everything but the editor.

The seasoned IntelliJ IDEA user would now ask, how is it different from "presentation mode" that is already available, or the full screen mode?

This is a very good question! Let's try to answer that! :)

Presentation mode

Presentation mode is designed essentially for delivering presentations. Some of my friends have adopted the presentation mode for actual coding. But to be honest, it only works fine if you have a reasonably large screen and you're not switching between windows while coding. This is how the whole screen looks like when IntelliJ IDEA is in presentation mode:

The default font size in presentation mode is much larger and can be configured in Settings -> Appearance & Behavior -> Appearance. Locate the setting at the bottom of the view:


Full screen mode

Entering the full screen means exactly that. IDE window will span the full screen area. On Mac OS X it also means that it will take the application window to another desktop, which I actually dislike very much, but it's rather a personal preference. In this mode, nothing is changed in the IDE window - all the toolbars, views, etc are preserved.

Notice all the control elements and widgets at the screenshot above?

Distraction free mode

"Distraction free mode" is actually just a fancy name that the marketers came up with :) In fact, it just means that by entering this mode you only keep the editor. This might sound like you're actually entering the presentation mode, it's an incorrect conclusion. In distraction free mode the IDE window doesn't expand to full screen and the fonts are preserved in the original configuration. Basically, we could call this mode as "Hide all toolbars" and it would probably confuse some users less.

At the screenshot above, you can see - it's only the editor that occupies the IDE window. No toolbars, no status bar, no additional views, nothing! So this is exactly what I wanted and I'm really pleased with the new feature! In addition, the text is center-aligned!

What's also cool is that in this mode I can still navigate the same way as I'm used to it in the normal mode. Navigate to the project tree:

... or call out the navigation bar:

Just have to learn the shortcuts ;)

P.S. The new distraction free mode is really cool. However, it is not quite new. In fact, all this was possible long before version 14.1. Even in earlier versions of IntelliJ IDEA you can achieve the same, just not with one mouse click or shortcut press. In the earlier Intellij IDEA versions, in the View menu, you could just hide the toobar, tool buttons, status bar and navigation bar and here you go - you have a "distraction free mode"! :) So the new feature isn't really new. It is rather just a convenience that was added on top of the existing features.

Tuesday, March 10, 2015

Packaging Java applications for Mac OS, javapackager

Stumbled upon an issue with installing muCommander on Mac. The native installer did not work, saying that the launcher is corrupted, but the portable version worked just fine via the command line:
java -jar mucommander.jar

Launching a GUI app from the command line is not convenient at all. One option is to assemble the *.app package using Launch4j. However, I didn't have enough patience to do apply the tool. So I tried looking for an alternative solution.
So I found this guide: Packaging a Java App for Distribution on a Mac. And the instructions worked just fine! Here's what I did:
1. Downloaded the appbundler utility from https://java.net/downloads/appbundler/
2. Create a build.xml file. For instance:
3. Run "bundle" task: ant bundle
Profit! :)
This is all cool and works, but the process is a bit clumsy. One has to download some strange utility and use a legacy build tool to assemble the final artifact. We should do better! So I found another documentation page: Java Platform, Standard Edition Deployment Guide: Self-Contained Application Packaging. Apparently, there's a javapackager utility included in JDK distribution that you can use to create native packages.
By running the following command in the same folder where mucommander.jar is located, it created the desired artefacts:
$JAVA_HOME/bin/javapackager -deploy -native -outdir .  -outfile mu.app \
-srcfiles mucommander.jar -appclass com.mucommander.Launcher -name "muCommander" \
-title "muCommander"
Voila!
muCommander-0_9_0 anton$ ls -l bundles/
total 269904
-rw-r--r--@ 1 anton  staff  75110066 Mar 10 23:53 muCommander-1.0.dmg
-rw-r--r--  1 anton  staff  63076596 Mar 10 23:53 muCommander-1.0.pkg
drwxr-xr-x  3 anton  staff       102 Mar 10 23:53 muCommander.app
The only missing bit there is a proper icon, which I was too lazy to bother about :)

Misconceptions about microservices

Every now and then I hear people asking questions like "How can I implement a microservice using Play framework?", or "How can I build a microservice using Spring Boot?". Every time I read this it sparks the "facepalming" reaction in me.

Repeat after me: microservice is not defined by a framework!

It doesn't matter what technology or a framework is used to implement a microservice. It is rather the domain or the functionality in isolation that defines it. Martin Fowler has written a nice article for defining the microservice and while he mentions the technology bit there, it's not about technology at all!

Captan Obvious says: if you use Play or Spring Boot to implement a microservice, it doesn't mean that those frameworks can't be used to build silos. Which also means that a microservice is a "mini-silo" :)

Monday, March 9, 2015

XRebel 2.0 Beta is available

XRebel 2.0 Beta is available for download! The new version includes profiling capabilities and it is now possible to get an overview of performance breakdown in a single HTTP request. The cool part is that XRebel shows only the minimal relevant information by filtering out a lot of irrelevant stuff. I have tested the new version with a lot of different enterprise-grade applications, including Atlassian Jira, Magnolia CMS, Liferay Portal, eXo Platform... and it works just great!

The greatest feedback so far was that the tool provided the ability to monitor JPA queries and the subsequent JDBC invocations in one go. With the new version, XRebel is turning into a real profiler, yet simple and powerful.

Monday, January 19, 2015

Groovy and Grails

The biggest today (19.01.2015) news in the community is probably the announcement regarding Pivotal pulling Groovy/Grails funding. And there are a lot of sad reactions on this in all channels that I have seen.

This might start a panic reaction around Groovy and Grails. IMO, there's nothing to panic about. Groovy and Grails communities are the healthiest and there's a lot of big companies that use Groovy and Grails and who would definitely be willing to sponsor the projects further. I'm pretty sure they all will be in line to get the both projects under their sponsorship just in a few weeks :)

All-in-all, it might even be very good for Groovy since Pivotal didn't seem to leverage Groovy in their ecosystem with the focus on Cloud Foundry offering. So we might even see an acceleration of Groovy/Grails development once the projects get a new sponsor.

Friday, January 16, 2015

Technology predictions for 2015

It is popular to announce predictions for the upcoming year. I though it would be fun to try predicting some stuff too :)

Disclaimer: my predictions are very subjective and are based on my not-so-huge awareness of the IT industry. Feel free to leave your opinions in the comments. So here it comes:

Big Data.

"How big is big?"- one would ask? I leave this question unanswered. But the term "big data" always reminds me of some data set that should be queried/calculated/analyzed etc. The thing is - enterprises are becoming data hungry. Even a small company internally generates huge amounts of data - website visits, emails, sale events, product releases, commits to version control - anything that comes up to your mind. This is all valuable data that can be analysed.

And it is a huge data lake that could be generated by data-intensive companies. Trying to keep the information structured was common just a few years ago - with data warehouse approach. Now we have technology that enables us to process so much data that the retail banking data warehouse would seem a child's play compared to the amounts of data processed today.

Now, where was I? Ah, yes... I you are an engineer and you still haven't learned about Hadoop, Spark, Storm, Kafka, Samza, Typesafe stack, or R, do yourself a favour pic one and start learning it! The demand in the skills for building data processing system backends will be huge in the upcoming year(s).

Want examples? How about Hortonwork's IPO? Startups being created to support Kafka? Or look at the awesome services being created for analytics!

It is just all about data now (it has always been). Business depends on it.

JavaScript and front end.

Business as usual. Every day a new batch of JS frameworks will be appearing. Nothing special. The efforts to make JavaScript better are definitely welcomed, but doesn't it bring some uncertainty - which JS framework would you pick for the new project? Angular? What do you think about Angular 2.0 then? What about Atscript? Dart?

Crazy stuff.. Don't get me wrong - the improvements and the progress are amazing in front-end tech. Compared to the time when I had to do JS coding the current work of front-end engineer is just pure pleasure! The problem that I see here: it is just never stable. Almost any front-end technology that is popular today might easily turn into unmaintainable in a few months. And it doesn't seem to get better, at least from my impressions. And this trend will continue.

JVM languages

Scala continues to grow, Java continues to decline. We will probably see more reports on Kotlin and Ceylon being used in real commercial projects. Despite all the recent efforts that have been done in Nashorn, I have lost my belief into dynamic languages, although Groovy remains my GTD programming language for JVM.

Microservices

Blah, blah, microservices, blah, blah, blah... The ESB of our time :P

The reality is, there are just a few companies, like Netflix, who would really benefit of microservices approach at a big scale. Others - just use the fancy term - microservice - and isolate some functions of the silo application into a dedicated service. That's it - "so micro, much service". So it's just a SOA reinvented. The community will realize it this year, I hope.

Docker

Docker is probably the biggest hype of 2014. Even bigger than 'microservices'. Well, now there's a competing effort - Rocket. I'm almost sure that in 2015 we would see some more challengers in this space - other competitors to Docker. Given the support of big vendors, however, Docker will continue the hype in 2015. I'm still not convinced by the technology though.

Technology marketing

Haha! You didn't see that coming, did you? :) Why technology marketing? Oh, because the most effective sales are not happening during a golf match any more. Even big vendors are now more developer-oriented. Hence marketing. The problem here - developers hate marketing.

But have no fear! Marketing guys are crafty as well - the new ways to deliver the message to developers about some new cool and shiny thing are being invented every day. How? Content. A huge effort is being put into creating content for software developers. Look, Voxxed have just been launched. Why? Answer - marketing.

So in 2015 you can expect even more content being pushed by the vendors related to the technologies I've mentioned above.

Done

OK, I think this is enough of predictions, it was a fun exercise :) Let's see how it turns out in a year.

Wednesday, December 17, 2014

XRebel 1.2

Just released XRebel 1.2. It is amazing, astonishing, splendid, beautiful, awesome, beautiful, beautiful, beautiful! :) I'm most pleased with its ability to show the relation between ORM-level events/queries and the generated SQL queries that are executed via JDBC. Like this:

Or even like this:

The cool part is that even with no special requirements to filtering, the call tree scales very well - the user could see the compact call stack with relevant branching points starting from the incoming HTTP request towards the JDBC calls, or NoSQL... or outgoing HTTP invocations.. even RMI!

/me happy! :)

Saturday, December 6, 2014

Java EE meets Kotlin

Here's an idea - what if one tries implementing Java EE application with Kotlin programming language? So I though a simple example, a servlet with an injected CDI bean, would be sufficient for a start.

Start with a build script:


And the project structure is as follows:

Here comes the servlet:


What's cool about it?

First, it is Kotlin, and it works with the Java EE APIs - that is nice! Second, I kind of like the ability to set aliases for the imported classes: import javax.servlet.annotation.WebServlet as web, in the example.


What's ugly about it?

Safe calls everywhere. As we're working with Java APIs, we're forced to use safe calls in Kotlin code. This is ugly.


Next, in Kotlin, the field has to be initialized. So initializing the 'service' field with the null reference creates a "nullable" type. This also forces us to use either the safe call, or the !! operator later in the code. The attempt to "fix" this by using the constructor parameter instead of the field failed for me, the CDI container could not satisfy the dependency on startup.


Alternatively, we could initialize the field with the instance of HelloService. Then, the container would re-initialize the field with the real CDI proxy and the safe call would not be required.


Conclusions

It is probably too early to say anything for sure, as the demo application is so small. One would definitely need to write much more code to uncover the corner cases. However, some of the outcomes are quite obvious:

  • Using Kotlin in Java web application appears to be quite seamless.
  • The use of Java APIs creates the need for safe calls in Kotlin, which doesn't look very nice.

Friday, August 22, 2014

MVC in Java EE

Java EE is getting MVC. And the crowd is going wild! :)

I'm actually quite positive about this move, although this came a little too late, in my opinion. Java EE has been criticised for not having MVC support, but it stayed opinionated and sticked with JSF. Apparently, MVC is actually a part of JAX-RS, so to speak. Not in the same spec though, it it will have integration points with JAX-RS. And there's also some sort of MVC support in Jersey already.

It is actually cool that it happened, just surprising that it took so long.

Friday, July 18, 2014

IntelliJ IDEA: Have you tried Search Everywhere yet?

The Search Everywhere action, invoked with double Shift key press, was added in IntelliJ IDEA version 13. I guess, most of the IDEA users/fans know about this feature and are enjoying it. At first glance, it just provides the means for search. You can search "everything": classes, files, symbols, actions, settings, etc. However, Search Everywhere widget is full of easter eggs.

Try using to jump between the search result groups. Or try left arrow to navigate in the history of search entries. But also, depending on the nature of the item that was found, the widget can provide some extra actions, like in the screenshot below: the "Show Navigation Bar" entry has an extra switch - on/off - showing that you can actually invoke this action.

Search Everywhere is a little gem in IntelliJ IDEA and all its features are yet to be discovered ;)



Tuesday, June 3, 2014

RebelLabs: Java Tools and Technologies Landscape for 2014

A great report on Java Tools and Technologies, aka JavaTnT :), was published just recently. As usual, one may say that those is a "biased" numbers. Well, the numbers might be biased. But it is not really clear, the bias agains/towards what?

There are discussions at Reddit and Hackernews about the report. Some would say that the numbers are legit. Some would say that the numbers do not make sense. Of course, the numbers do not make sense if you don't like them ;)

In any case, the results present the JavaTnT landscape pretty well. It would be nice if more people would care to enter their data during the survey instead of arguing about the numbers afterwards. Oh well.. first world problems :)

Disqus for Code Impossible