I recently interviewed Sharon Chiarella for The AWS Report. Sharon is an Amazon Vice President with responsibility for the Amazon Mechanical Turk. After we talked about the Mechanical Turk concept in general terms ("a marketplace for work,") we zoomed in...

Java architect certification training lab is an interactive learning and assessment material for OCMJEA (formerly SCEA) certification, developed and published by EPractize Labs. The exam kit provides enough study notes and practice questions with brief explanations for the certification preparation. This Training Lab is bundled with set of mock exam questions and review slides to gear up self preparation. It is developed by experienced Java experts with review tips, real-world program examples, and challenging practice exams that systematically prepare you for the actual exam.

James Phillips presents the origins of NoSQL, followed by a comparison of various NoSQL solutions and ending with an architect's view of Couchbase. By James Phillips

Let's take a quick look at what happened in AWS-land last week: Monday, July 30 Our friends at Netflix published the code for their Chaos Monkey, a member of their Simian Army of testing tools. You can now buy EC2...

Philip Wadler discusses second-order quantification, from its inception in the symbolic logic of Frege through to the generic features introduced in Java 5, touching on aspects of faith and evolution. By Philip Wadler

The ExecutorService feature came with Java 5. It extends the Executor interface and provides a thread pool feature to execute asynchronous short tasks. There are five ways to execute the tasks asyncronously by using the ExecutorService interface provided Java 6. ExecutorService execService = Executors.newCachedThreadPool(); Preview Text: ...

Zach Tellman provides advice on calling Java libraries from Clojure, exemplifying with Clojure code drawing graphics on the screen using the Java2D library. By Zach Tellman

Cloud Computing is creating substantial changes to the usual way of doing business. How should organizations leverage this approach to improve testing and quality assurance of software? To get an answer, author Forrest Shull spoke with James Whittaker from Google about cloud computing testing. By Forrest Shull

Overview of the 5 basic strategies for dealing with optional dependencies in Java libraries and frameworks, with a discussion about use cases, advantages and disadvantages of each strategy for both the end-user and the library developer.

In current post we are going to see how to use JaCoCo Jenkins Plugin to have an overall code coverage statistics of Maven projects that contains more than one module.

After selling out a London Java Community meetup (so to speak), it seemed rude not to catch up with one of the key men behind the radical rethinking to JVM garbage collection, Azul Systems’s Gil Tene. Here’s Part 1 of our chat, delving into different approaches, the origins and upcoming trends. Make sure to check back on Wednesday for part two of our exclusive interview. JAX: Obviously garbage collection has been around for decades - can you detail the origins of GC? Gil Tene: The wider way of looking at garbage collection or automatic memory management is something that has been around for quite some time, probably a good four decades with a lot of good academic work on it - interestingly a lot of that was done during the 70s and 80s and more groundbreaking stuff recently. What is garbage collection good for? It seems sort of obvious but a lot of people seem to think of it as ways to let lazy programmers that are not very skilled still program. But I think there are very important industry trends that come out of it and now that Java and other platforms are dominant in parts in the industry, we can see the effect of what that does to actual productivity. JAX: Does it differ depending on the working environment? GT: The first thing is that if you work in a mixed environment, or compare environments where people code in Java or C# to those programming in C and C++, what they do is build applications that support, maintain and enhance over time. They don't look at the time to initial delivery so much as a year and a half or two years into a project. My experience of embedded systems, servers and software you shift is that when the stuff is built in C and C++, you get it stable, you get it shipping and then you have these rare things that crash and you spend about half of all your engineering efforts trying to figure out what the rare crashes are. When you look at core Java, they spend their time debugging other things. It's not that they don't have bugs, but it's very rare that they look for crashing bugs, they usually end up looking for functional bugs, enhancements and slowness and other things. The other part that is not so obvious. Automatic memory management is a core requirement almost for an effective framework ecosystem and leveragable software. That is not an obvious thing to most people. JAX: So do you think Java developers, in general, care enough about GC? Do they put it at the back of their minds? GT: I think they predominantly don't care. And I think that's the right way - they shouldn't care. When they run into tuning in production, they end up caring for practical reasons but I actually think the term GC-friendly programming or heap-friendly programming is a symptom of a really bad execution on a garbage collection side, not a good thing for programmers to do. Saying heap-friendly programming is kind of like saying 16bit-friendly programming. It should be considered that way. If a collector can't give you the invisible experience, then the collector's broken, the JVM's broken and it's a toy that isn't working right and you should be programming better. JAX: Shall we move on to more specific garbage collectors and what typical things they do? GT: I think that if you look at garbage collection implementations, the modern mature runtimes such as Java and .NET, Ruby and others - the evolved garbage collectors which are pretty good. Usually you'll see precise garbage collectors, one that knows where all the pointers whenever it collects, so it can move objects around for example, it can compact memory. You can't do that if you can't fix the pointers. As far as techniques go, there's no commercial JVMs that don't do that, it's a given. Generational collection, observation that young generation focus on recently allocated objects produces efficiency - again it's a universal practice and every JVM on a server. There's ways to run without that, but usually you don't get very good throughput or scalability. JAX: What particular trends appear to coming through, particularly in a Java context? Over the past 15 years, certainly since Java started, we keep improving garbage collection but the way people tend to improve it is by taking the really bad thing that's happening and trying to make it happen a little less often. So, pushing it into the future and further into the future rather than taking it on and figuring how to solve it. JAX: Does that mean the mindset needs to change dramatically? GT: I think so. In effect, our design for GC started nine years ago. It was started from the simple statement of saying that that trend is not sustainable - we have to go in the exact opposite direction. Rather than figuring out how to take a problem and ignore for a little longer. Instead of a few seconds, it's going to be a few minutes, maybe hours. That's the Microsoft Windows 95 approach to stability. And we stopped making fun of Windows laptops and rebooting because Java needs to rebooted more often than a Windows laptop. The opposite direction is find that thing, solve it and maybe by solving it, all this other crud you had to do avoid it, doesn't even have to be done. That's the choice we made nine years ago. So far, I don't see it as something the industry has followed but I do think that it is unavoidable that everybody will have to choose that other path. The path of delaying the problem even longer is running out of steam. Or arguably already has run out of steam five or six years ago. Within that, there's various modes. You've got non-compacting collectors, the fall-back compaction, incremental compaction, default and full compaction. Then there's mostly concurrent, mostly incremental, mostly non-stop the world. The word mostly means, sorry I can't deliver except for some of the time. All those are common exercises in delaying. Every time you add to them you buy a little more time. JAX: To an outsider, the jargon with garbage collection can be a bit perplexing at first. Can you attempt to classify the key terms? I have this talk (see below) which defines terms, types and classifies metrics and puts it all together to classify modern collectors. I like to distinguish concurrent collection from parallel collection. Concurrent collection happens without stopping the application, parallel collection can use more than one thread at a time. browser does not support iframe Understanding Java Garbage Collection and What You Can Do About It: Gil Tene from jaxconf JAX: Obviously Azul Systems has a spin on things - care to explain how Zing differs? The C4 collector has two main behaviors that are visible from a classification perspective. First, it has got a single pass concurrent marker. Guaranteed, regardless how fast you change or mutate the heap, the marker will always complete and never have to revisit what you've touched. Because of that it is independent of application throughput. It has a concurrent compactor that allows us to move objects without stopping the application and more importantly allows us to fix pointers without stopping. That's one of the key difference from the other commercial collectors. It has this for both the old gen and the new gen - it's actually the same collector. It has zero stop the world fallback code. In practical terms, this results in a compactor that is not sensitive to heap size, it's not sensitive to allocation rate or mutation rate. None of those things will affect pause time or response time. JAX: I'm guessing it thrives under high pressure situations? GT: It does very well but actually it was designed to work across the whole spectrum. JAX: What mistakes are common when tackling garbage collection? GT: From a developer perspective, obviously I'd like to see people use those collectors and never look at them. But given that Zing in its native Linux form is a new thing, relatively young less than a year, the same techniques aren't available on other vendors. I think developers do what they have to do and use a lot of duct tape and work with reality and make their applications work as well as they could be expected to. So when I see people program in a GC-conscious way, I don't think they're doing something wrong. I think it's sad that they have to do that. But good engineers have to solve real world problems. Part 2 of our interview with Gil will appear on Wednesday, where we discuss his company’s role in the Java Community Process, and Java 8. Photo by brianfuller6385.

Azul Systems have announced that they are making their pauseless Zing JVM freely available to Open Source developers and projects for use in development and testing. By Charles Humble

I read a good article tonight about implementing application level logging using log4J, and I thought this concept could be extended and abstracted one level further by making use of the Apache Commons Logging API. Using the Apache Commons Logging API allows the logging implementation to be abstracted away from the application; resulting in application logging code that can be reused even...