September 25th, 2013


My first session of the day was by Markus Eisele. He grouped the bad practices in developing Java EE application into seven groups labeled by the seven deadly sins. Did you know that the SpongeBob animated movie characters were prototyped exactly following those sins (lust, gluttony, wrath, greed, envy, sloth and pride)? I didn’t J

So here is a list of some of those “smells” outlined by the speaker that we all should avoid in our projects:

  • Avoid over-engineering: write interfaces only if you really need them (especially in Java EE apps)
  • Don’t try to implement all the design patterns you read yesterday in the GoF book, etc.
  • Living on the cutting edge might sound cool, but if you plan to sell something, make sure you don’t depend on 0.0.1-SNAPSHOT libraries or languages
  • Minimize your build and deploy time. If your build takes one hour, that’s not good
  • Try not to mix complex technologies in one application (Spring and Java EE for example)
  • People are not resources, two junior developers do not make for one senior
  • Don’t be lazy and constantly do refactoring and peer reviews
  • Avoid vendor lock-ins if the specification does not cover something

“I can do it better!” Really?

(Hard) Core Java

Last year I visited Charles Nutter’s (a.k.a. the JRuby guy) session on JIT compiler optimizations and learned so many things about the nuts and bolts of what happens under the hood in the JVM. I even blogged about it. So this year I decided to go to both his talks: on invokedynamic and on the path from Java to assembly code. I must admit that I did not understand much of the things, but I will try to share what I got.

So, most of the people thought that the invokedynamic feature (and everything that JSR 292 brought) is there just to suite the dynamic languages on the JVM. Because they had to do all kinds of equilibristic in order to shoehorn into the Java virtual machine. Most of you who have developed in JRuby or Scala for example may have noticed the tons of anonymous inner classes generated in your classes directory. And this is just the tip of the iceberg. So definitely the invokedynamic helps a lot here. It adds several new things:

  • A new (terminal) byte code instruction (not surprisingly called invokedynamic), besides invokevrtual, invokeinterface, invokestatic and invokespecial
  • The method handles
  • The bootstrap methods

Let’s look to the last two elements.

In a nutshell, method handles are a better way to call methods than with java.lang.reflect.Method. Not necessarily faster (or at least not before Java 7 update 40), but better. Essentially, MethodHandle is an object that points to a method of a certain class with certain name and certain parameters of certain MethodType. Besides invoking them, you can do things like inserting parameters, changing parameters, deciding whether to invoke the methods based on a guard condition and all other cool stuff that you would usually do with a byte code manipulation library. And everything gets optimized by the VM!

What is a bootstrap method? Whenever a compiler (not JIT, but rather javac, scalac, groovyc, etc.) decides that it should insert invokedynamic instruction, it adds there the address (in the constant pool of course) of a bootstrap method. This is a standard Java method, which acts as something like a factory that finally produces method handle and passes it to the VM.

This is how the Java 8 lambdas work (and that’s the only thing I got from the second session ;)). Whenever javac sees lambda expression, it inserts in the byte code the invokedynamic instruction that points to a [bootstrap] method in the LambdaFactory class (part of the JDK). The latter returns a method handle to method, generated again by javac, which body contains the lambda code itself.

It’s interesting to know the Java internals in order to see what javac and the JVM do for you. But don’t use that for optimizing your programs before you have fixed all the problems that a standard profiler can find. Which appear to be 99% of all the problems in a project.

Maven to Gradle migration

This was actually a BOF, which didn’t answer the question how, but rather why you should do that. And of course the reason “Because everybody says that Gradle is cool” is wrong and can create yet another Cargo cult. Another wrong answer is: “Because you write in Groovy and not in XML”. It’s not so hard to change Maven’s input format, but it will not fix its problems:

  • It is hard to use in big projects (LinkedIn for example have 3600 modules): the build takes too long, can’t be easily parallelized, incremental build does not work properly
  • In big projects the normal maven plugins and workflow does not suit you, so most of the time you need to customize the build. However, writing a new plugin is pain, so people prefer writing ant or python scripts

For most of the projects Gradle can convert the pom.xml to file. No matter which path you prefer to do the migration: automatic or manual, the speakers advised that you write a test that check the output of the old build and compare it with that of the new approach.

Of course, as they stated, today it’s easy to hate Maven. But let’s not forget what it did for the industry: it introduced convention over configuration way before Ruby on Rails, it established the practice to have common project structure and is much more understandable than ant or make.


Here are some links to the previous blogs about this years JavaOne:

JavaOne 2013, Community Day
JavaOne, DayOne records

September 24th, 2013

by Ivan St. Ivanov

Today was JavaOne’s first conference day. I went to many sessions, some of which were really geeky. The speakers spent most of their time in the development environment showing cool techniques in the respective topic. So it is pointless to report anything lengthier there. But in a few sentences:

Adam Bien talked about writing enterprise apps with… JavaFX. Besides giving some insight in the enterprise patterns, he showed a neat way how you can implement dependency injection when you are not in the managed environment of an application server.

JBoss’s Andrew Lee Rubinger and Aslak Knutsen presented their new book and showed some interesting approaches in testing non-Hello-World Java EE applications. I could learn how you can test asynchronous methods with java.util.concurrent.CyclicBarrier and how you can verify that your RESTful web service follows the HATEOAS principles.

At the end of the day I attended an hour and a half long tutorial on writing given DSL in Scala and Groovy. It showed the constructs in the two languages that are used for implementing one and the same thing.

Here are some more details about the other sessions:

Groove your SAAS

I visited a session about using JVM languages to configure your application. And I was positively surprised on how interesting it appeared to be. It was given by two Amadeus employees. Their company provides IT solution for the travel industry. They offer hotel/ticket booking application together with its hosting on their data centers. Initially it was pure Software as a Service (SAAS) allowing the customers to only change things like colors and themes. However, soon they realized that in certain countries specific features were required. For example in Sweden they wanted to be able to book a taxi together with their plane ticket (otherwise they may freeze to dead while waiting outside the airport ;)).

So that is why they decided to let the customer develop their custom code, which would hook into the application by calling its (Java) APIs. The customer code is loaded and executed by the main application. After a short research they decided to use Groovy for the custom coding. There are many approaches to run Groovy code inside a Java program, but they decided to go for the JSR 223 way. This JSR defines a standard way how you can call programs written in any programming language from Java environment. The target language has to only provide a Script Engine implementation. Already 20 languages have that (Groovy, Scala, Jython, JavaScript among them).

However, this was not all that they had to do. The customers were sharing common hardware resources. Not only that, but some of them were running inside one and the same JVM. So theoretically if the customization written by one customer calls System.exit(1), this will bring down the whole server, together with the applications of the other customers. That’s why they decided to implement checks on script compilation level before deploying the script into the server environment. They used Groovy’s Abstract Syntax Tree (AST) manipulation capabilities in order to prohibit some non-allowed method calls (part of a black list). The same functionality was used to add wrapping code that would check at runtime if there are bad code constructs that was not caught on the previous step.

This was really an eye opener for me. If you are server provider and want to let your application developers use different languages, you don’t have to write a different server in different programming language for that. You can do that in Java and use JSR 223. The specification is available since Java 6, but unfortunately lacks things like giving access to the binary code after it is compiled (so that it is not compiled again the next time the same script is executed) and you have to take care about the security concerns by yourself. But if there’s a will among the big players in the industry, this can be improved with the next version of the spec. And with the growing popularity of the scripting languages I think that it’s really time to look at that JSR.

Adopt OpenJDK

Last year’s JavaOne I got intrigued by the Adopt OpenJDK program, which aims at individuals, JUGs or even companies to implement certain features from OpenJDK and to contribute them to the central repository. And thus helping Oracle with testing, improving and delivering faster the new releases of Java’s reference implementation. Unfortunately in the last year I didn’t do much to get our JUG involved in this effort, but I may say that with the help of another JUG member we are already there and soon will present to the Bulgarian Java community what we have in mind. However, we had some questions before that and my JavaOne attendance was a perfect fit for finding the answers.

This morning I went to an introductory talk on this topic. Even though I have read numerous wikis on the topic, it was interesting for me to find that 75% of the code in the repository is Java, 12% being C++ and other 8.5% – C. A good step in Java-ifying more and more code is project Graal, which goal is to re-implement parts of the JVM in Java. Projects like Sumatra are built on top of that.

The OpenJDK project has done a lot in the last year to attract the developers with the facilities like mailing list, twitter account, blog aggregator. There is even a wiki page and a modern bug tracking system. You can read all of those freely, but you have to have OpenJDK account if you want to post.

After the session I caught the speakers and posed the questions that I planned to ask before I left to San Francisco. And now I am pretty confident that soon we can bootstrap our OpenJDK effort in Sofia.

Java EE 7

Every conference in the last couple of years had at least one or two talks on What’s new in Java EE 7. Even my fellow blogger Stoyan has written a post on it. So I didn’t plan to write much on the “Java EE 7: making easy even easier” session that I attended. But at the end I was happy to find that there were a lot of things that were new to me, which I will happily share with you.

The speakers were Oracle’s Arun Gupta and the lead of the JBoss Forge project Lincoln Baxter III. I will not repeat here things like JMS 2.0, REST client API or web sockets. You can read about them in almost every Java EE 7 article issued in the last few months. Here are though some things that are worth mentioning:


  • As of Java EE 7 all the APIs are accessible in the central maven repository under the javax:jee-api:7.0 GAV address
  • You can @Inject now everything, not only CDI beans
  • beans.xml is not mandatory anymore to enable CDI. However, if you create it, you can specify inside whether CDI should be turned off or should be turned on just for some of the beans

JPA 2.1

  • The server providers must provide default JTA data source. So if your persistence.xml does not contain the jta-data-source tag, that default data source will be used
  • You (or your DBA) can write your own DDL scripts and let the entity manager use them for creating the tables schema instead of building it based on the entities declaration
  • You can add index declaration to your @Table definition

Declarative transactions

  • It is no longer necessary for a component to be an EJB in order to be run in a container managed transaction
  • You can declare a method as @Transactional and the container will automatically execute it inside a transaction
  • You can declare a bean as @TransactionScoped and the container will create a distinct instance of it for every new transaction (and will fail if it is called outside transactions)
  • Remark: Hello, Spring! 😉

Batch processing (JSR 352)

  • Again something that was heavily influenced by Spring
  • You define an XML that contains a sequence of steps. Every step has one or more chunks. A chunk has three stages: read, process and write. For every stage you specify which bean should be called
  • You write @Named beans for every stage (its name should match to the configuration in the batch.xml) that respectively read the data from a certain input source, process it if needed and write it back into the output source
September 23rd, 2013

by Ivan St. Ivanov

The 18th JavaOne conference just started. It’s the second one for me, so I got the ALUMNI strip on my badge.IMG_20130922_215039

In the next few days I will try to cover the key stories and messages that I caught while attending the conference sessions and events. Of course, I will start with the


As always, we have the three keynotes in the community day of JavaOne: the strategy keynote lead by Oracle’s vice presidents, followed by the sponsor keynote from IBM and finally Oracle architects and distinguished developers gave us the technical keynote. The good thing this year was that the whole session returned to Moscone center.

The big message today (and not only from the keynotes) was that the technology world is moving to the Internet of Things (IoT) and Java is the best platform to make it happen. What does this IoT term mean? In the recent years there’s a boom of non-human devices that can connect and communicate with each other. And in the near future the number of these devices will grow more and more. People in Oracle see that and make sure that Java virtual machine (ME or SE embeddable) is running on every possible device. In the recent years Java ME was far behind Java SE: its different profiles (CLDC and CDC) had very limited subset of the SE APIs and the language level was at Java 1.3 and 1.4.2. So the plan is for the next release (Java ME 8) to bring language features like annotations and generics to that edition as well as more APIs from the JDK.

On the other side of the fence we have the devices and the one that has most attention in the last couple of years is the Raspberry PI. It’s a very cheap computer (25-35$) that has a 700MHz ARM processor, 512 MB RAM, SD card, very decent GPU, USB, HDMI and Ethernet ports. It has also low-level GPIO port, where you can plug various sensors for example. But most importantly: it has Linux operating system installed and you can have Java on it. To that extent that you can run an application server like Glassfish for example. So the Java developers can pick up their Java skills, get the hardware and turn their home to home 2.0.

I attended a session particularly in that topic. A guy from the SouJava user group showed a demo with two Raspbery PI’s, a few Arduino’s and some home devices that offered a connection (a fan, a robot and a popcorn machine). One of the PI’s was acting as an app server hosting a RESTful service. The presenter was sending it requests to get the current temperature and humidity, which were dispatched to the Arduino’s. The latter had some sensors installed. The speaker issued also some voice commands to his phone, which resulted in making the robot turn its head on 100 degrees and the popcorn… popping corn.

But anyway, let’s get back to the keynotes. The IBM keynote was focused on the fact that nowadays developers are the most important (as opposed to the sales and marketing guys). Today with all these free tools, languages, platforms, APIs and hosting environments the path from idea to profit is smaller than ever. It takes just three steps: develop, deploy and get the money.

The speaker mentioned briefly two interesting technological efforts by IBM:

  • IBM BlueMix: combine in the cloud (powered by CloudFoundry) two types of systems:
    • Systems of engagement: they are based on mostly mobile applications, focusing on the processes of a regular person (how could I get to the airport, what’s the weather at my target destination, what are the best hotels and restaurants when I arrive)
    • System of record: our favorite enterprise systems (HR, ERP, CRM, DataBase) that provide services consumed by the systems of engagement
    • Packed Objects: an idea of how to better represent objects in memory. Think of a hashmap containing millions of entries and all the needless headers that comprise the memory consumed by the hashmap

The technical keynote started as it used to start in the last couple of years: with the state of the lambda. Finally we are very close to having it shipped. It was interesting for me to learn that the lambdas are the biggest change to the Java platform since its beginning. It’s a synchronized effort in all the areas:

  • Change in the Java language with the new ‘->’ construct
  • Change in the virtual machine: the authors wanted to optimize the byte code that is generated and use the invokedynamic stuff rather than generating anonymous inner classes
  • Change in the APIs so that they leverage (I like this word!) the new Lambdas. As Brian Goetz mentioned: “If we don’t use lambdas in the Collection API, which looks ancient even now, it will look more ancient in Java 8”


We saw other cool stuff in this keynote. NetBeans guys are doing some great things: as of 7.4 you can change your HTML5 code in the IDE and immediately see the results in the browser, you can debug in parallel your client and server side code, etc. The JavaFX folks besides all the 3D eye candy showed their own home made tablet (called DukePad), which was based on (surprise!) Raspberry PI.

The final touch of the demo was Mark Reinhold’s vision on the future of java beyond Java 8. It includes modularization (Jigsaw), leveraging the power of the GPU (Sumatra), reified generics, JNI 2.0, memory efficient data structure (like IBM’s packed object) and many more.

Java Communities

The JavaOne Sunday is all about that: communities. And more precisely Java User Groups (JUG) talks, NetBeans sessions and more recently meetings about the Adopt a JSR program. This year I attended mostly talks on running a successful JUG. As a member of the Bulgarian one, I would like to bring in some experience. There are four basic topics that I would like to outline here:

Organization and mission

Every user group that I listened to had kind of a board. It’s a group of people that makes everything running. Sure you can’t run a user group alone, as all of the members have their daily job and usually don’t have too much time for JUG activities such as: finding venues, organizing meetings and hackathons, finding topics and speakers, bringing sponsorship, etc.

A good user group has to have also its mission so that the board can concentrate on organizing events around that. This mission can be broad, but surely should be written down and made public. For example something like: “Share knowledge amongst the Java developers in Bulgaria. Participate in one of the Adopt a JSR programs. Help in networking between developers and recruiters.”


A successful JUG should organize consistently events (mostly talks). These should happen on a regular basis and once a month is a good starting point. Most of the presenters shared that they have strict day for that, for example every third Thursday of the month.

Events should also follow strict agenda. Something like first fifteen minutes for pizza and networking, next fifteen minutes for announcement and sponsored talks (read on about that), next one hour or one hour and a half for the real talk(s) and finally time for networking and beer.

The venue where the meetups are organized should also be as consistent as possible. Or at least should be easily reachable, especially in the end of the business day when there’s a lot of traffic in the city.


Right now our Bulgarian JUG does not have direct sponsors. Of course we use the Telerik Academy conference room whenever we need it, but we do not consider that as sponsorship. The user groups which I watched today have developed this much more (most probably because they are in the US, where everybody thinks in business terms ;)).

Basically there are two kinds of sponsorship. The easy way is when the sponsor just buys the food and drinks or provides the venue. For that they are allowed to have a 15 minute session. However, this should not be a high level talk that just presents sponsors’ product or their hiring proposals. It should be 75% technical with very little sales pitch at the end.

The other kind of sponsorship is the one when the JUG is registered as a non-profit organization so that it can directly receive money from the companies that wish to sponsor it. This way the user group board has the funds to hire a venue, to buy the giveaways and even to invite speakers that do not live in the area.

Where to find sponsors? First among the JUG members’ employers. Then in the technological companies in the area. How to persuade those companies to sponsor the JUG? By proving that our members are very talented and motivated enough to attend the talks.


Having regularly JUG events brings another challenge to the board: they have to find speakers for every meetup. We have a lot of talented people in Bulgaria, but some of them don’t want to speak in such events, others are not good speakers, etc.

Another aspect is having a big Java rock star give a presentation now and then. Unfortunately Bulgaria is not often visited by such rock stars, so the only way to get them is if someone pays for it. It could be a sponsor, but also it could be a company that will send them to evangelize a product or technology (think about Oracle paying Martijn Werburg to come to Sofia to pomote Adopt Open JDK). And here by paying here I mean things like flights and hotels. Most of the Java rock stars don’t require fees for talking to JUGs.

Of course the board should be well prepared for situation when there is no speaker found. So they have to be ready to give a talk on a certain topic. Which does not mean that they should be the only speakers.



The community day finished with the community awards event. The leaders of 11 projects got the Duke Choice Award. One of them was the University of Belgrade, nominated for their achievements in the neural networks. I am wondering is there a chance that one of the big Bulgarian Universities gets such an appreciation ever? Just wondering…