by Ivan St. Ivanov

Community keynote

The last JavaOne day started with the community keynote. All the conference attendees gathered in the Continental Ballroom of Hilton hotel and cheered Sharat Chander, the conference chair person, who opened the session. He started his talk with the fact that this year 60% of the content at JavaOne was delivered by the community (and just 40% by Oracle). I felt from his words that the Java stewards had really got it: you cannot move Java forward without significant effort from the people who are using it.

Then on the stage came Donald Smith, director of product management at Oracle. He took over from Sharat and tried to cheer up the crowd by asking us to make one of those Mexican waves that you see on the stadiums. He then asked Gary Frost from AMD to talk a little bit about Project Sumatra. In my opinion, the announcement of Project Sumatra is news number one of this conference. Maybe it’s not really news as it will be based on a project that exists even now: Aparapi. But it’s something tremendous for the Java world. Its basic goal is to move the parallelism on the next level: from the cores of the central processor to the GPU. Gary showed us some demos on the performance of applications which require intensive calculations. The Paparapi enabled runs were way much faster than those that just used threads. The goal is that for Java 8 Paparapi’s APIs become even sexier with the introduction of lambdas and in Java 9 it is expected to be inside the JVM.

After that Donald invited for a panel discussion people from Eucalyptus, Twitter (Chris Aniszczyk), Cloudera, Eclipse Foundation (Mike Milinkovich himself) and Perrone Robotics (its CEO Paul Perrone), who represented the different types of participants in the Java ecosystem. What I will take with me from the short question and answer session was that entrepreneurship is not about venture capitalists, but about innovators. And that the more open your innovation is, the better ideas you get.

Then Georges Saab, VP of development at Oracle, welcomed on the scene Martijn Verburg (a.k.a. The Diabolical Developer) from the London Java Community. Martijn explained how this user group was formed: people who were not happy of what they were doing in their day-to-day jobs in the London city gathered and decided that instead of complaining and writing bad tweets, they could do something good. And thus the adopt a JSR and adopt open JDK initiatives were born.

And here came the quote of the day. Martijn said that the queen has told him that “if the presidential elections [in US] don’t work well, she is ready to take [the states] back as a colony.”

After we had Paul Perrone again on the scene to show one of his robots it was time for the biggest surprise of the conference: James Gosling, the father of Java, who left Oracle and never showed up on JavaOne since then, was back on the scene! This provoked great cheer and applause from the crowd (including myself). Welcome back James!

For the rest of the session James talked about the things he has been doing in Liquid Robotics, but the most important part for me was what we heard at the end by Sharat: reach out the youths and inspire them!

Project Errai

This was a talk given by my two new friends from JBoss: Christian Sadilek and Jonathan Fuerth. They are working on a relatively new and quite impressive project: Errai. In a nutshell, it’s a project that lets you write your web applications just in Java, it is based on Google Web Toolkit and brings you such things as CDI and other powerful Java EE APIs on the client side. Its mantras are:

• Declarative works
• Boilerplate sucks
• Code it once

The most important project features (some of them already mentioned) are:

• Unified programming model on the server and on the client
• Java EE 6 APIs (including dependency injection and most importantly CDI’s event model) available on the client
• The web application project has three basic folders: server, shared and client. The shared and client folders are compiled to JavaScript
• You can easily do remote calls from the client to the server using RPC and REST
• The objects that travel between the client and the server should be annotated as @Portable and may not have getters and setters

Then the speakers did a demo which showed some of the most impressive Errai features. They renamed one of the API method names using refactoring in the IDE and all the classes that used this method (including those on the client side) were updated accordingly. They then changed the path of the RESTful service endpoints at just one place and it worked out of the box for all the parties involved. But the most impressive thing was the fact that clients could observe server generated events: the speakers added a new entry from one browser session and the other session was updated without any refresh.

At the end Christian and Jonathan talked a little bit about some cool new features of the framework. You can use JPA annotations and entity manager on the client, which will result in persisting your data in HTML5’s local storage.  You can use HTML5 design templates for describing your UI in declarative way instead of the standard procedural approach of GWT. Errai takes care for binding your data objects’ fields to the HTML elements they correspond to.

Really interesting session and great work. You should definitely give Errai a try!

Testing JSF apps with Arquillian

This was the final session that I went to at this JavaOne. The speakers were again from JBoss. They are company’s representatives in the JSF expert group: Brian Leathem (project lead of RichFaces) and Lincoln Baxter III (project lead of Forge).

I found this talk as a sequel of the one about Continuous Development. The speakers started with the well known fact that unit tests with mocks are not testing the application in its normal environment, which make them not very useful. And they prepared the audience with a quick HelloWorld-like example of an Arquillian test, which showed how you can unit test your code without mocking what the container does for it.

If you want real test, however, you need to test your UI. And if it is a web application, then libraries like Selenium 2 and Web Driver come to the rescue. Unfortunately in your tests that use those APIs you need to write a lot of boilerplate code: initialize the web driver, start the browser and then shut it down. All this boilerplate is spared for us by an Arquillian extension called Drone (led by another cool JBoss guy whom I met here – Karel Piwko). The way Arquillian brings the container to the test, Drone brings the browser to the test. So there you annotate a WebDriver field of your class with @Drone and the library does all the plumbing code for you. You can additionally configure what kind of browser you want to test against.

The next project from the UI testing stack that was presented was another Arquillian extension: Graphene. It runs on top of Drone and brings much more injection to your test. Common practice in Selenium 2 tests is to make plenty of findElementById calls in order to see or change the content of an HTML element. Good practice used in web testing to make this more type safe is the Page Object pattern: you encapsulate all these calls in one class (called page object) and expose more meaningful methods to the client. So you have getUserName()  instead of findElementById(“userName”).getValue(). This pattern is abstracted very well by Graphene, which provides you with such annotations as @PageObject and @WebElement to further relieve you from writing the plumbing code.

Finally we came to the point of testing JSF pages. Brian and Lincoln presented us a third Arquillian extension, suitable for that: Warp. It is a relatively new project and its basic goal is to provide some features that JSFUnit lacks (like making assertions around all the phases of the JSF page lifecycle).

The session ended with some best practices when writing Aruillian tests:

• Use remote target container, which is running, so that Arquillian doesn’t have to start it and stop it for you upon each test
• Reuse browser sessions between tests
• Use ShrinkWrap micro deployment instead of packaging your whole application

Conclusion

My first JavaOne is over. And to be honest, I liked it. Until now I always tried to follow blogs like this in order to get what is really going on at the conference. I still read them, as I can’t visit every session. But now the feeling is different: I don’t just read the reports, I feel like I participated there.

Next year? Well, maybe,… nobody knows! Now it’s time for packing and for the next conference: Java2Days in Sofia.

by Ivan St. Ivanov

Who is more functional

The first session that I attended today was in the early morning slot, when JetBrains’ Andrey Breslav (the leading designer of the Kotlin programming language) compared four languages (Java 8, Groovy, Scala and Kotlin) in terms of being functional. The comparison was done following four criteria: availability of recursion, no side effects done by the language, higher order functions and availability of abstract and algebraic data types.

I must say that the no side effects part was most interesting for me. All of you have heard the ‘immutability’ mantra. This is a very popular word in today’s programming. Everything should be immutable so that our code can be parallelized easily and reliably and take advantage of the multiple cores of the CPUs. Immutability implies that there is no shared state between two objects, so the execution of an operation of one of them cannot potentially cause side effects on the other one. The operation (or as it is called in the functional programming – the function) just takes some parameters, does something without changing them and returns a result. Talking about side effects, according to Andrey writing to a file, to the network or even to the console is a side effect. That’s why all the compared languages failed to meet this criterion.

Another very interesting aspect of functional programming was also mentioned. FP is cool and makes you look smart, but this doesn’t mean that you must use it for every feature you develop. For example the functional implementation of the Fibonacci numbers algorithm is much slower and takes more memory, than the classical (iterative or von Neumann) approach with a loop. So there is always this tradeoff between clean code and performance that you should consider.

Another corner stone of the functional programming are the higher order functions (or lambdas, or closures, or what not). Instead of explaining what they are (most of the people visiting JavaOne should know them very well), Andrey pointed us to one of the patterns in the GoF book – the strategy pattern. It’s implemented most intuitively with lamdas in mind. Think about filtering the content of a collection. Instead of getting an iterator out of it, then iterating it, then creating the new collection based on a certain predicate, you just call a filter method with the predicate (or a strategy) as parameter. This is something that was also mentioned by Brian Goetz during the technical key note: the knowledge how to apply the function on the elements of the collection should be in the collection itself and not in the client code. As the collection knows best how its content is structured and organized and can do the job in most efficient manner.

The two ADTs (abstract and algebraic data types) represent the interfaces that define contracts and the data classes. The availability and ease of use of the latter is key to functional programming. Modern languages (like Scala and Kotlin for example) have case classes and easy pattern matching when working with them. While in Java you have to do:

 if (dataType instanceof Type1) {...}
 else if (dataType instanceof Type2) {...}

Which is not really elegant.

The final functional aspect that was touched was the ability to extend (or open) existing classes without changing their code. In Java it is not possible – you cannot add a new method to the String class for example. While other languages have it in some way or another: the expando meta class in Groovy, the implicit conversions in Scala and extension functions in Kotlin. In Java the standard approach is by creating static utility methods in other classes (Collections, Strings, Arrays classes are such examples).

Very interesting talk. Andrey as always was trying to provoke audience’s participation: he had funny slides, asked questions, stopped the presentation when somebody had a question.

Continuous development

Another agile software engineering (ASE) talk. It was given by my JBoss buddies Andrew Lee Rubinger and Aslak Knutsen. They are most known by their leading the Arquillian and ShrinkWrap integration testing projects. However, the focus of this talk was something beyond testing, which appears to be the focus of their upcoming book: continuous development. So after continuous integration and continuous delivery, we are now looking at the continuous development.

The core of the continuous development process is to write code, which is able to be tested. The tests should be portable to any environment. In the enterprise world this translates ‘to any container’. They should be executable without any tweaking both from the IDE and as part of the build. They should also leverage existing testing frameworks like JUnit or TestNG in the Java world and not make up ones of their own.

Before giving us these rules, the speakers talked a bit about testing in general, as it is the most important part of the continuous development. As Jeremy Norris had stated, “The purpose of automated testing is to enable change. Verifying correctness is just a nice side effect.” Another very important thing about testing is that it makes you use your own API and thus get an early feeling whether it is good and usable. Andrew didn’t insist that you should follow the test-first approach. Just make sure that at the end you have automated tests for all your features.

The next big topic in the talk was unit vs integration testing. When you unit test a piece of code, which interacts with other objects, you usually have to use stubs or mocks in order to be able to test that piece of code in isolation. But is this isolation always a good idea? Using mocks takes your class outside of the environment it usually runs in. Thus you miss large portion of the picture. This was a nice intro to the Arquillian framework (or library, or model…). If you are doing Java EE development and you haven’t heard or are not using Arquillian, then you should consider doing it.

The rest of the talk was a demo of some of the aspects of the continuous development:

• Using Arquillian persistence extension to test persistent data by easy way of preparing the initial and the expected data sets
• Using Arquillian Graphene – the enhancement of Selenium browser automation library
• Using the cloud and Openshift in particular for running your own continuous integration server
• The hotswapping capability of Openshift: while debugging your cloud application you can change the code locally in the IDE and it gets automatically updated on the remote location

Behavior Driven Development on the JVM

The agile track continued for me with the next session. It was John Ferguson Smart’s about modern JVM tools and frameworks for doing Behavior Driven Development (BDD).

The talk started with a theoretical introduction which, as John said, was more for the Business analyst type of people (nobody in the audience confessed to have such a role). The first thing about BDD is that it advocates common language between all the participants in a project: the business analyst, the developer, the tester and the customer. You don’t really write tests in BDD, you rather create specifications. This does not mean 100-page word document, but stories following a specific format. The most common such format is the “given, when, then” triad.

The stories should describe the most relevant features of the product as seen by the final user. Which are the most important features? Well, according to the speaker, those that meet the goals of the project and bring value (in terms of money).

The agile approach of defining stories is: as a ‘role’, I want ‘…’, so that I achieve ‘…’. According to John the order should be changed and the last section should come first – the reason why we need a feature is the most important incentive for doing it.

The second part of the session was on existing BDD frameworks in the JVM world. The first two presented were jbehave and cucumber. The common thing about them is that you define the stories in human readable style in a text file and then write annotated Java code where you state your given, when and then functionality. Next was easyb, BDD library with a Groovy DSL, where both the rules and the code are at one place. This sounds good, but the code may become unreadable for more complex tests.

A forth library was also presented. It is the one developed in John’s company and is called Thucydides. I have read quite a few articles and blog posts about it, so I kind of knew what it was doing. So, its basic idea is to encapsulate any existing BDD library (those from above and also many more, Selenium 2 for example), to run the tests, observe their results and report what happened (with many screenshots). Just a side note, John approached the Forge team after the talk as he was very interested in creating a Thucydides plugin that could spare its users writing some boilerplate.

The final part of the talk was called BDD for developers. It was about BDD frameworks that replace existing unit testing frameworks and the best one here is definitely Spock. It’s again based on Groovy-based DSL and follows the given-when-then style of writing unit tests. It has its own mocking framework that is easier to setup and use even than Mockito. It’s quite easy to write data driven tests as well (remember the Parameterized JUnit test cases?). Then the speaker spent some time talking about Spec2 (which is the same as Spock, but with a Scala DSL) and Jasmine, which is the same for JavaScript.

The slides are already available on SlideShare so you can go and check them out.

What’s new in Groovy 2.0

This talk was given by the Groovy language project lead Guillaume Laforge. It was the informative kind of talk, one of those where you don’t have too many funny slides or some philosophic diversions.

Actually Guillaume talked first about the Groovy 1.8 new features, as they are also very interesting and important:

• After 1.8 Groovy is even better for creating DSLs as there are now a lot of other possible situations where you can drop your dots and parenthesis: in functions with multiple arguments, when you have named arguments or closure function parameters and even no arguments at all
• GPars, the Groovy parallelization library providing such features as actors, fork/join, map/reduce, parallel arrays, etc. is now part of the official distribution
• Annotations can take closures as parameters. This is very useful for validation frameworks for example: you can define your rules as boolean functions and attach them to your model as annotations
• There’s now built-in JSON support, the same as the XML support – with the slurper and builder objects
• A groovy compiler plugin can do some transformation on your code before translating it to byte code, based on common annotations. For example, if you add @ToString or @EqualsAndHashcode, after you compile, you’ll automatically get toString(), equals() and hashCode() methods (something like Lombock for Java). I counted more than 10 possible transformations on the slide, but there was no time for the speaker to talk about them all

And now for Groovy 2.0. It’s major release so you may expect something really major inside. However, Guillaume started with the (in my opinion) not the greatest new features.

So, as of 2.0 Groovy is more modular. Instead of needing to download the big 6MB jar that has it all, you can download just the core (3MB) and the modules that you might need for your application. There’s now another way to extend existing classes (like the expando meta class): the extension modules. There you have to do some more plumbing code like adding some files in the META-INF/services directory of the jar, but now the static compiler (ooops, spoiler!) and the auto-completion of IDEs can really understand that the class is extended with your own methods. Groovy has now full support for all the Project Coin enhancements (multicatch, binary literals, etc.) and also for the new InvokeDynamic functionality of the VM. The speaker mentioned that the Oracle engineers have some more work to do for invoke dynamic, as for now there is not a big change in the performance of Groovy code.

And now for the most prominent part: if you wish, you can make Groovy type safe! And this can be done in two ways:

• Ask the compiler (and IDEs) to check for things like wrong method and variable names in the code, executing methods that are not part of the called type or return wrong result types. You just annotate your class or method with the @TypeChecked annotation and voila! The compiler will check all those things for you. Beware that inside such code blocks you cannot do things like parsing or creating XML or JSON as the API there relies on the dynamic features of the language
• One step further is the static compilation: it not only checks for compilation errors, but generates byte code, which performs much better at runtime.

At the end Guillaume showed some benchmark results for Java, Groovy with static compile and older Groovy versions. And the result showed that the compiled Groovy is just slightly slower than Java is. Nevertheless, I’m sure that there will still be people that will continue saying that Groovy is slow. To be honest, they look to me like the folks who keep telling for the last 15 years that Java is awfully slower than native code. The history repeating?

Functional style of programming in Java

My day 3 started with functional programming and ended with the same topic. The speaker was John Fergusson Smart again (this is his third session that I attended this JavaOne).

The talk kicked off by introducing the main concepts and advantages of the functional programming style and they were basically the same as in Andrey’s talk in the morning:

• Immutability is your friend: it makes your code thread safe. Unfortunately you cannot have true immutability in Java as even private final fields can be changed with reflection
• No side effects: no matter how many times you call your functions, they give the same result for the same set of parameters
• Avoid using loops: leave that to the library that you are calling, just tell us what you want, not the way how to achieve it

John then showed us how you can do most of these things in Java 8 with project Lambda. But… Java 8 will not be here any time soon. So if you need something now, you’ll have to look at the libraries that are available now in the ecosystem. So the speaker presented us two such libraries: Google Guava and LambdaJ.

The Guava part of the talk was relatively short, most probably because most of the functional features there are based on using anonymous inner classes. There are immutable collections in the library. They are immutable in a sense that you cannot add or remove element to them or change their order (by sorting for example). But the immutability of the elements themselves is not enforced. The ‘don’t return null’ programming style is also addressed. If you intend to return null for some reason in your code, then consider returning Optional<?> type. This looks and behaves much the same as the Scala Option type. And this was it for Guava…

The rest of the session was about LambdaJ, which seemed to be John’s favorite FP style library. Its APIs for collection operations like filter, sort, aggregate, convert, etc. are quite better than Guava’s. The magic is that it integrates with the Hamcrest matchers (usually used instead of the JUnit asserts in your tests). An very good example of the integration is the filter method:

filter(startsWith(“P”), arrayOfNames);

Here filter is LambdaJ static method and startsWith is Hamcrest matcher method. There are plenty of matchers and it is very easy to create one of yours, so you can easily do without any anonymous inner classes. Sometimes your code might not be very readable as the design of the Hamcrest APIs was not really intended for such use. In such cases John’s advice was to encapsulate the matcher code in your own method, give this method a meaningful name and use that in the LambdaJ functions.

At the end John showed a benchmark, according to which LambdaJ performs relatively slower than the iterative code (with loops). D?j? vu: the same thing was mentioned by Andrey Breslav in the morning, so again you have to make the trade off: readability or clean code.

As always, the slides are available on SlideShare.

Conclusion

This was my day 3: functional programming and agile software engineering. And finally I could get some sleep (Oracle, thank you for that!). The quote of the day was by John Smart: “The amazing thing about [the JavaScript BDD library] Jasmine is that it exists”.

by Ivan St. Ivanov

Continuous delivery

My first session of the day was John Ferguson Smart’s on Continuous delivery. Being a fan of the agile software engineering (ASE) practices, this topic was particularly interesting for me as the title and the abstract of the talk promised that we’ll see some best practices in the area. To be honest I’m not a blind follower of everything that ASE prescribes. In my opinion applying every practice on all projects is unnecessary. However, the continuous integration to me is vital, not less than having unit and acceptance tests for example. The most important reason for that is that, as the speaker mentioned, it gives you regular feedback on how your project is going.

The most important continuous delivery principles are the following:

• Every build, i.e. every commit, is a potential release
• You shouldn’t have some kind of QA department that runs 6 week test cycles before you go to production
• Automate as much as possible
• Trust your tests, be confident that you are ready to go productive

The focus of the talk was on how you can use Maven and Jenkins to ensure a successful continuous delivery process.  However John stated that Maven’s snapshot builds contradict a little bit to the first principle of the process. What he proposed in this case is that you should use the version plugin after a successful build, give your snapshot a real version (for example 1.0.123, 1.0.124, etc.), run the acceptance tests and then publish.

Some other best practices mentioned by the speaker were:

• Never use the Maven release plugin (to be honest, I don’t remember why)
• Use Failsafe plugin for running tests instead of Surefire. Have separate configurations for running quick junit and slower integration tests
• Don’t do mvn deploy on every module of a multi module projects. Because if one of the projects’ build fails, the others will not be run and your central repository will have different versions that might not work together. First do mvn install and do the deploy only after everything passes successfully
• Deploy to production should be a manual operation. It might be triggered by your continuous integration server, but it should definitely ask you for approval before doing the real deploy

Finally John showed everything in action. He presented the Jenkins configurations of a project, where he basically explained the different steps of the build pipeline.

The presentation is already available on slideshare. Be sure to check it out if you are doing continuous integration and delivery.

JVM JIT for dummies

The next session that I attended was Charles Oliver Nutter’s JVM JIT for dummies. JIT stands for Just-in-time compiler and it is the module, part of the JVM, which is responsible for optimizing the executed code while the program is running. I got a little bit interested in this topic after reading these two excellent posts on JavaWorld (and the third one is still to come). The speaker, also known as the JRuby guy, is doing compiler optimizations for quite a few time now in his effort for better performance of that language. It was a really informative session and the author explained the matter in a way that even a dummy like me could understand most of it.

So, when you run javac, the source code is compiled into byte code. Which is then interpreted by the virtual machine. But if the story would end here, the Java programs would not perform as well as expected. That’s where the JIT compiler kicks in. It performs various optimizations on code that is executed very often (10 thousand times is the default threshold). These pieces of code are called hot spots (hence the name of the virtual machine – HotSpot). These optimizations may include:

• Compilation of interpreted byte code to native code
• Inlining method bodies in calling sites to avoid executing a separate method. In that direction Charles showed the assembly code for a method that returns the sum of its two parameters. It contained one instruction for calculating the sum and 7-8 more for doing the method call and return the result – what an overhead
• Loop unrolling – whenever the number of iterations of a loop is clear, just execute their body for as many times to avoid moving the instruction pointer
• Lock coarsening and eliding – moving and removing synchronized blocks when appropriate
• Escape analysis

Then the speaker continued explaining the different types of HotSpot virtual machines:

• Client virtual machine: it is optimized for fast starts. Doesn’t do too many optimizations besides a few inlines
• Server virtual machine: does aggressive inlines based on profiling during the application “warm up”
• Tiered virtual machine: takes the best of both worlds. It starts quickly like the client VM, but after some time starts profiling and optimizations

Then Charles showed the different HotSpot compiler options (those that start with -XX) which help you to fine tune it as well as to monitor things like native compilation and method inlining. He explained in details what the different entries in the monitoring meant. Finally he advised us to always use small methods as large code cannot be inlined, and also not to use long method call chains.

Forge in action

Next up was a talk very anticipated by me. JBoss Forge is the open source project to which I occasionally contribute some small changes and bug fixes. The speakers were the project lead Lincoln Baxter III and one of the most active contributors outside JBoss: Paul Bakker. There was one more reason why I was interested in this particular session – I am going to talk about Forge at Java2Days conference in Sofia in less than a month.

So, what is actually Forge? It’s a tool that helps you bootstrap your application (be it desktop, web app or a simple library). That’s what Maven also does with its archetypes, but the latter stops there. While Forge continues to help you integrate all the technologies that you need whenever you need them: persistence, RESTful web services, integration tests, anything that you might imagine. It also relieves you of memorizing, googling and copy-and-pasting all the different code snippets that you might need in order for you application to run: pom.xml entries, persistence.xml, etc. The first time you do it, it might look interesting. However with every new application this repetitive boilerplate would drive every developer mad. And the best thing about it is that Forge creates the bare minimum of artifacts so that your project is not polluted with stuff that you might not need later (Maven archetypes again?).

After the short introduction, Lincoln and Paul proceeded to the demo, which took pretty much the whole talk. Basically Paul played the part of a curious developer that wanted to develop a task tracker web application and Lincoln added feature by feature using Forge. I’m not sure whether I ever mentioned that it is a plugin based command line tool, which integrates great with the Eclipse IDE in its own view. So Lincoln created a new maven project for the application that they planned to develop. No, it was not done with the Eclipse wizard, but using the according tool command. Then he continued setting up and adding new functionalities. And Forge did whatever was requested reporting the incremental changes that it made. It was smart enough to keep in sync with the changes done in the IDE. Lincoln also installed plugins that were not part of the tool core – these tool extensions were on Github, Forge downloaded the code, built it and integrated it in a breeze.

Even though Forge has a massive number of existing plugins, sometimes you may want to do something that nobody has developed functionality for. Doing it by yourself is not a big problem: writing a plugin is quite an easy job. There’s a pretty comprehensive guide on plugin development at the tool’s website. And the greatest thing is that anyone can contribute their plugin: push it to github, register it in the repository and boom! everybody is able to use your functionality. This is what I call social coding!

If you are interested and are going to Java2Days or Devoxx, make sure to visit the respective talks there. And if you wish to contribute, this is the mailing list, so join in!

Some BOFs

At the end of the day I decided to visit a couple of Birds-Of-a-Feather sessions. You remember, these are talks on a very specific topic, which are usually attended by the most interested (and usually advanced) developers. The topics that I went to watch were about things that I plan to bring home and follow up after the conference.

The first BOF was about JEDI – an educational initiative by the University of Philippines and Sun (now Oracle). They have created (and most importantly, keep up-to-date) materials for nearly 20 university courses. Starting from Java 101 and covering such topics as web development, web services, mobile development, security, etc. The courses are free (licensed under the Creative Commons license) and besides in the Philippines, they are taught also in Brazil, Vietnam and Indonesia. As an assistant teacher in our University of National and World Economy, I got very interested in the project and will contact our professors and see whether it is possible at all to use these courses (the documents are written in English).

The second BOF was on the Adopt OpenJDK project. As I wrote in my first JavaOne blog, I got very interested in this topic and plan to propose it to our JUG when I get back home and even start doing bugathons. While I was drinking a beer in the Buzz House (IBM sponsored street spot, where JavaOne attendees have beer and coffee for free) during one of the afternoon breaks, I met Ben Evans, one of the London Java Community leaders. I asked him to give me some more details and possibly contacts for any question. And he told me about the Adopt OpenJDK BOF later in the evening.

So I went there. First it was Cecilia Borg, who spoke. She is product manager from Oracle and former JRockit and HotSpot developer. She is responsible for so to say facilitating from Oracle’s side the communities contributions to the OpenJDK. So, there is already a JIRA bug tracker set up (as presented by another prominent Oracle employee – Joe Darcy) and they expect to have soon test infrastructure and code reviewing tool.

To be honest, I expected something different from this BOF – a session on the whole bugathon process from finding what we want to fix to getting the source code, building it, doing a change, running the test suite and commiting it back. But anyway, not a big worry, I am glad that at least I know whom to approach and where to read if our JUG decides to embrace this idea.

Conclusion

It was a busy day at JavaOne for me, much busier in terms of conference sessions that I attended (I even went on two more, but I didn’t find it useful to blog about them). I will conclude this post with the quote of the day. This time it was Charles Oliver Nutter (the JRuby guy): “I don’t really know assembly language. But I fake it very well.”