Last week I was invited again to give a talk at the annual developer day of Swiss Railways (SBB).
As every year the conference was a great event with many great sessions and interesting discussions during the breaks.
My talk was about how JavaScript can fit into a Java ecosystem.
avatar-js.jar from the java.net Maven Repo.avatar-js.dylib from the java.net Maven Repo..so file from ../libavatar-js-linux-x64/0.10.25-SNAPSHOT/.dll file from ../libavatar-js-win-x64/0.10.25-SNAPSHOT/avatar-js.dylib and rename the jar to avatar-js.jar and put both in a directory called distapp.js:java -Djava.library.path=dist -jar dist/avatar-js.jar app.jsServer running at http://127.0.0.1:8000/
I am naively playing around with Nashorn. Nashorn is the new JavaScript Runtime that comes with Java 8 and runs on the JVM.
I am using the current Build b132 of the Early Access Release of Java 8 on a recent MacBook Pro (2.3 GHz Intel Core i7)
One of my first experiments is comparing performance with node.js.
I have run the following script with Nashorn and with Node:
The results:
Nashorn:
✔ jjs fib.js Input: 30, Time: 66 Input: 31, Time: 40 Input: 32, Time: 58 Input: 33, Time: 90 Input: 34, Time: 154 Input: 35, Time: 242 Input: 36, Time: 348 Input: 37, Time: 556 Input: 38, Time: 920 Input: 39, Time: 1483 Input: 40, Time: 2426 Input: 41, Time: 3928 Input: 42, Time: 6360 Input: 43, Time: 10303 Input: 44, Time: 16602 Input: 45, Time: 26802 Input: 46, Time: 43384 Input: 47, Time: 72201 Input: 48, Time: 116425 Input: 49, Time: 188520 |
Node:
✔ node fib.js Input: 30, Time: 13 Input: 31, Time: 20 Input: 32, Time: 33 Input: 33, Time: 53 Input: 34, Time: 88 Input: 35, Time: 142 Input: 36, Time: 226 Input: 37, Time: 365 Input: 38, Time: 590 Input: 39, Time: 954 Input: 40, Time: 1530 Input: 41, Time: 2522 Input: 42, Time: 4047 Input: 43, Time: 6534 Input: 44, Time: 10557 Input: 45, Time: 17161 Input: 46, Time: 27712 Input: 47, Time: 46323 Input: 48, Time: 73521 Input: 49, Time: 118905 |
Pure Java:
✔ java -cp fibdemo.jar FibDemo Input: 30, Time: 5 Input: 31, Time: 6 Input: 32, Time: 11 Input: 33, Time: 18 Input: 34, Time: 27 Input: 35, Time: 45 Input: 36, Time: 71 Input: 37, Time: 121 Input: 38, Time: 188 Input: 39, Time: 304 Input: 40, Time: 490 Input: 41, Time: 804 Input: 42, Time: 1276 Input: 43, Time: 2067 Input: 44, Time: 3361 Input: 45, Time: 5445 Input: 46, Time: 8901 Input: 47, Time: 14253 Input: 48, Time: 23288 Input: 49, Time: 37160 |
Out of the box the performance of Node seems to be almost a factor 1.6 better than of Nashorn.
Of course this naive experiment is not representative for real world performance and this is still an early access release of Java 8. It might well be that the performance of the final release will be better. Also the JVM can probably be tuned in many ways unknown to me.
Still I would be interested in thoughts about the findings of this experiment...
Vert.x is a very interesting project that brings some fresh concepts to the JVM platform. At first glance Vert.x looks like a Node.js clone for the JVM. But there are differences: Vert.x can not (yet) offer the gigantic ecosystem of modules of Node.js, but it is certainly attractive for bringing a "Node.js-like" programming model to the proven and scalable JVM platform. With its distributed event bus and the concept of "worker verticles" Vert.x offers concepts that go beyond Node.js.
Packt Publishing sent me the Book "Instant Vert.x" for review.
Instant Vert.x is a short book (54 pages). As the name suggests, you can read it in "an instant" and it gets you bootstrapped into the world of Vert.x.
I liked the style of the book: it is short and concise and after reading it, you have a good overview over Vert.x as an application platform and the programming model that comes along with Vert.x.
However I have to note that the Vert.x project has a very nice online documentation. In my opinion the book goes not beyond the information that is also available online.
The advantage of the book is, that it structures the information in an easily digestible way that you can read in chunks offline. However I would have hoped for more "in-depth" information or some "best practices" how to use Vert.x in real projects.
If you have never heard of Vert.x, I can fully recommend "Instant Vert.x". If you have already played with Vert.x the book is probably not for you.
The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved. There will come a point where the accumulated complexity of our existing systems is greater than the complexity of creating a new one.
Es könnte alles so einfach sein, ist es aber nicht.
Getting EJB Remoting to work in JBoss 7 was probably the most pitfall-ridden path I have travelled so far on my journeys through the swamp of frameworks…
Note: The example and discussion in this post is based on JBoss EAP 6.1.
It all started out well with a simple quick-start: ejb-remote.
But the pitfalls lured …
TL;DR: Finally I got an illustrative example running, which will be the base for the following discussion. The example can be found on my Github repo.
The EJB is simple: [Gist]
It's in the client where we find the pitfalls: [Gist]
Let's discuss the pitfalls:
When you deploy the EJB into JBoss you get a nice output in the server-log:
[0m23:18:42,226 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-12) JNDI bindings for session bean named HelloWorldBean in deployment unit subdeployment "ejbremote-ejb.jar" of deployment "ejbremote-ear.ear" are as follows: java:global/ejbremote-ear/ejbremote-ejb/HelloWorldBean!net.jonasbandi.ejbremote.server.HelloWorld java:app/ejbremote-ejb/HelloWorldBean!net.jonasbandi.ejbremote.server.HelloWorld java:module/HelloWorldBean!net.jonasbandi.ejbremote.server.HelloWorld java:jboss/exported/ejbremote-ear/ejbremote-ejb/HelloWorldBean!net.jonasbandi.ejbremote.server.HelloWorld java:global/ejbremote-ear/ejbremote-ejb/HelloWorldBean java:app/ejbremote-ejb/HelloWorldBean java:module/HelloWorldBean
It looks easy … but actually none of those JNDI bindings work for remote lookup!
You can use the "standard" JNDI lookup (which uses the "remote-naming project") or the the (proprietary) EJB Client API. Both approaches differ in the initialisation properties (key-value pairs) that have to be configured and in the JNDI lookup name that must be used for a given bean.
The EJB Client API is recommended. Loadbalancing, clustering and client interceptors are only available with the EJB Client API. Also it is performance optimised. [see here]
I do not understand the following properties (except that they all have something to do with client, context and naming):
jndiProperties.put("jboss.naming.client.ejb.context", true);
ejbProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
ejbProperties.put("org.jboss.ejb.client.scoped.context", "true");
Yet you have to use the correct ones for the correct lookup approach, else it won't work…
There are also a lot of other properties floating around in different documentations, wikis, forums and JIRA issues … I did not find a authoritative documentation about them.
Runtime dependencies are tricky. You can get you code compiling, but it will not work unless you have the correct runtime dependencies configure. Getting the EJB client API running, you need:
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-ejb-client</artifactId>
<scope>runtime</scope>
</dependency>
Getting the "standard" JNDI lookup running (including JNDI tree traversal) you need:
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-remote-naming</artifactId>
<scope>runtime</scope>
</dependency>
In both cases you need some more runtime dependencies which are listed in the client pom.xml of the example.
Example 1: If you configure the wrong version of the ejb-client dependency like:
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-ejb-client</artifactId>
<scope>runtime</scope>
<version>1.0.5.Final</version>
</dependency>
Then you get an exception that makes you beleave you have made a mistake somewhere in the security-configuration:
javax.ejb.EJBAccessException: JBAS014502: Invocation on method: [] is not allowed
Example 2: If you pass a number instead of a string for the port configuration like this:
ejbProperties.put("remote.connection.1.port", 4447);
Then you get the same exception as when you use a wrong JNDI lookup name:
java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:ejbremote-ear, moduleName:ejbremote-ejb, distinctName:]
Since JBoss 7.2 you can use scoped contexts and then you would not need do programmatic initialisation of the EJBClientContext.
So if you do this:
ejbProperties.put("org.jboss.ejb.client.scoped.context", "true");
… then you do not need to do the following:
final EJBClientConfiguration ejbClientConfiguration = new PropertiesBasedEJBClientConfiguration(ejbProperties); final ConfigBasedEJBClientContextSelector selector = new ConfigBasedEJBClientContextSelector(ejbClientConfiguration); EJBClientContext.setSelector(selector);
However if you do the above, then the programmatic registration of a client interceptor does not work any more. I suspect this is a bug?
In a later post I plan to elaborate on how to get the above example running with a custom login module and with a cluster setup… be prepared for more complexity and more magic strings!
This week I was invented again to speak at the SBB Developer Day 2012.
My presentation was about vert.x:
I enjoyed the event very much, and I hope to be invited again next time.
This short speech from JavaZone 2011 is just ingenious! It really made me laugh out lout again and again.
I can fully recommend to watch the video (it's only 9 min), you will be amused, even if you don't know much about hibernate...
Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity. from JavaZone on Vimeo.
Favorite quotes:
Frameworks like Hibernate leave you with pretty much exactly the same amount of work you had to do anyway, only now you are not enjoying it at all.
I present to you: Hibernate - the naked emperor's hairy butt-cheeks!
If Hibernate was a part of your team, you wouldn't even let him anywhere near your database.
We used to write algorithms, now we are writing annotations. Are we meant to be happy about that?
$JBOSS_HOME/client) on the classpath since the RMIAdaptor is a type that is provided by JBoss.$JBOSS_HOME/bin/client) on your classpath even though you don't explicitly import types provided by JBoss. java.net.MalformedURLException: Unsupported protocol: remoting-jmx Can you spot the difference:
Scala is a serious option for organizations developing on a JVM platform.
The friction and complexity that comes with using Scala instead of Java isn't offset by enough productivity benefit or reduction of maintenance burden for it to make sense as our default language.
Ha ha ha ...
Cuke4duke is a ATDD/BDD tool for the JVM. The tool is based on Cucumber and uses JRuby to execute.
<plugin>
<groupId>cuke4duke</groupId>
<artifactId>cuke4duke-maven-plugin</artifactId>
<configuration>
<jvmArgs>
<jvmArg>-Dcuke4duke.objectFactory=cuke4duke.internal.jvmclass.PicoFactory</jvmArg>
<jvmArg>-Xdebug</jvmArg>
<jvmArg>-Xnoagent</jvmArg>
<jvmArg>-Djava.compiler=NONE</jvmArg>
<jvmArg>-Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=y</jvmArg>
</jvmArgs>
mvn verify), then Maven breaks and waits for a debugger to connect:
[INFO] [cuke4duke:cucumber {execution: run-features}]
[INFO] Listening for transport dt_socket at address: 4000
org.jruby.Main
${M2_HOME}/repository/.jruby/bin/cuke4duke ./target/test-classes features
-Dcuke4duke.objectFactory=cuke4duke.internal.jvmclass.PicoFactory
Lessons Learned from Java EE is an interesting presentation by Rod Johnson.
Trolling with Java Web Frameworks.
I don't think you can count someone even as a semi-decent java dev until he wrote his very own web framework at least once in his life (from here)
I updated the entry for Behavior Driven Development on Wikipedia.
BDD is a second-generation, outside-in, pull- based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well- defined outputs, resulting in the delivery of working, tested software that matters.Watch his talk for an explanation of this definition...
The foremost feature of Maven that comes to mind is probably dependency management. Maven probably standardized dependency management for the Java platform. That’s probably also the reason for its wide adoption.
At this time there are already several attempts for smaller and easier solutions that repackage the ideas about dependency management from Maven. Their promise is to be a cleaner and easier to use.
Foremost there is Ivy, which provides Maven-like dependency management for Ant.
There are even two JRuby projects that bring simplified Maven-like dependency management to the JVM: maven_gem and javagems.
Especially interesting is Grape, which provides dependency management for Groovy at a language level (by integrating Ivy).
I think these examples are an impressive demonstration how the Java platform grows and how good ideas and concepts are adapted and evolved.
There is advice out there, that it is a good idea to use Groovy for unit-testing your Java code.
The following developerWorks article is a good example for this idea:
Practically Groovy: Unit test your Java code faster with Groovy
...in order to achieve the goals of TDD, unit-tests should be written in the same language as the underlying code.
Manning was so kind to send me a copy of ActiveMQ in Action.
Programming consists of overcoming two things: accidental difficulties, things which are difficult because you happen to be using inadequate programming tools, and things which are actually difficult, which no programming tool or language is going to solve.
Recently I realized that there is a third kind of complexity that is especially dangerous:
There are different options for configuring maven plugins in a POM-hierarchy.
A plugin can be defined and configured in a parent-POM. Then it is executed for the parent itself and for all its children.
This is achieved in the build->plugins section of the POM.
A plugin can be configured only in a parent-POM and selectively included in any child of the parent. Then the plugin is only executed in the respective children.
Configuration happens in the build->pluginManagement->plugins section of the parent POM.
Activation in a child happens in the build->plugins section of the POM.
References:
Maven Doc: Plugins
Maven Doc: Plugin Management
Sonatype Blog: Optimal Maven Plugin configuration
