Skip navigation

What happens if you configure a Hadoop-centric scalable big data infrastructure running on the Amazon EC2 cloud, that's programmed to perform some very basic processing on delimited ASCII data records (about 30 characters in each record), and you feed it a single data record? How quickly do you think that massively powerful system would process that teensy, trivial input data set? Milliseconds? Microseconds? Nah, surely that type of system would blast through a single record in nanoseconds, right? Or even picoseconds or femtoseconds or attoseconds? In zeptoseconds? Yoctoseconds? (Anyone know what comes next?)

The answer, as it turns out, is 34 seconds. I found this out in the Wednesday JavaOne session Pragmatic Big Data Architectures in the Cloud: A Developer

There are a great many sessions at JavaOne 2013 that feature JavaFX. But only one of them dared people to attend the session. That session would be No Guts, No Glory! A Deep Dive into the Internals of JavaFX [BOF5802], presented by Steve Northover, Kevin Rushforth, and Richard Bair (all of Oracle). At first, I was wondering if the challenge would mean I'd arrive at the session, only to find myself turned away because the room was already filled to capacity. But, no such luck!

So, after I entered, as the three peered my way from the front of the room (the session was already under way), I ducked behind the last row of seats and, still maintaining a low profile, crept forward until I found a seat that was partially obscured from their view, but which still offered a vantage point from which I could conveniently observe the proceedings.

Indeed, this was a session which exposed (sometimes seemingly without intention) some of the historical guts of JavaFX, along with its current guts. There were several moments when one speaker strayed a bit too far into the past, and started to reveal secrets the team preferred to keep buried -- at which point another of the three would step in with a word or two to get the speaker refocused on the bullet points on the slide deck.

Seriously, though, this was a superb session for anyone who has followed JavaFX throughout its history (as in, at least back to the 1.x days), and who's wondered how in the world they get all those fancy dancing Dukes to come into being. Did you know, for example, that a screen that has a basically static background, save for a sine wave whose frequency and amplitude is constantly varying that runs from the upper left corner of the screen to the bottom right corner of the screen is a very problematic situation for JavaFX (and, undoubtedly, other graphics rendering libraries) within the context of a great many graphical output devices? This is because that silly little wiggling line causes the construction of a spatial container that's as wide as its amplitude that extends from the upper left to the lower right of the entire screen. And every time the amplitude or frequency of that line changes, a recomputation of the pixelation that's required for drawing that entire huge portion of the screen is required, even if the rest of the screen isn't changing at all. This requires lots of memory. It's like having to recreate very big objects repeatedly, quickly...

And consider: for each new diagonal sine wave, you also have to redo the antialiasing computations in order to avoid a horrid jagged pixel effect. Heaven forbid me wanting to throw in the added wrench of requiring each peak of my sine wave to be labeled with text that reads "Amplitude"! Antialias moving characters as well??? It's enough to make a JavaFX architect throw up his hands in dismay -- and move to the next slide.

Then there's that damned stuff that's made of molecules that you have to cope with: hardware. If only the world was made only of software! Then we wouldn't have to cope with problems such as the design of modern high end graphics boards -- which are tuned for great performance in displaying the type of graphics output by modern games, not dumb fluctuating diagonal sine waves.

At that moment, I decided that my very next experiment with JavaFX was going to be to make a simple dynamic XY plot of that labeled fluctuating diagonal sine wave... And I began to think of other devious complications -- "enhancements" to the design, so to speak...

Sensing this, the JavaFX team shifted their strategy, and moved to slides talking about the future. You see, today, JavaFX only utilizes two threads: a UI thread that works with FX nodes, and a Render thread that works with NG nodes (which need a name change, since "NG" stands for "New Graphics" and that name is old, not new). But, as we all know, many modern devices have many more than two cores. So, what if JavaFX was enhanced such that it could use all available cores? Then the graphics would render that much faster.

Bang! That idea immediately bumps into an OpenGL graphics card wall. You see, OpenGL stronglyprefers a single incoming thread. So, just replicating the current model by a factor of N (where N might be a bit less than the number of cores divided by 2) -- that is, having N UI threads and N Render threads -- is virtually a non-starter on OpenGL devices.

So, how to efficiently draw my beautiful fluctuating labeled diagonal sine wave? One option is by modifying JavaFX to utilize command buffers. For JavaFX, this would mean creating multiple UI threads to utilize the available processor cores, then striping all the UI thread results back into a single data entity and converting it into a package handed off to a single Render thread, which arrives smilingly single-threadedly at the OpenGL door.

This possibility convinced me that it was now safe for me to retreat. So I silently rose from my seat and walked back and out of the room -- safely shielded by the start of the Q&A portion of the BOF.

Enlightening, indeed!

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed.

-- Kevin Farnham (@kevin_farnham)

Government... Isn't interacting with it your favorite social pastime? What? It's not? OK, so what don't you like about it? What? You're saying that, in your country, you can't just log into your favorite government sites and experience speedy, reliable, secure services?

I'll guess, then, that you must not live in Ecuador... Poor you!, don't feel too bad. From what Java Champion Jeff Genender, CTO of Savoir Technologies, and Savoir Senior SOA Architect Johan Edstrom told us in Monday's JavaOne 2013 session Building a Country on Java Open Source [CON3674], even for Ecuadorians things weren't always what they are today. For example, things were so bad back in 2007 that Ecuadorian President Rafael Correa(pictured left) decided something had to be done. He demanded that government agencies switch away from a widely variant mix of proprietary software components to open source software. Rafael's vision was that the Ecuadorian people should own their software, not pay license fees to foreign corporations and run code they cannot freely access and modify to suit their own needs.

So, the Ecuadorian government agencies made modifications to comply, by working toward a standards-based platform. The only problem, Jeff notes, was that the underlying "standard" platform that was chosen by most of the agencies was the Microsoft platform... Well, isn't SOAP open source?

Unfortunately, this first attempt at implementing government services using open source software based on the Microsoft platform proved problematic, in terms of performance, and in various other ways. Strangely, after quite a lot of effort and expense, the services being provided by the government to Ecuadorian citizens seemingly hadn't improved all that much... It all came to a head in 2012 when someone hacked into all of the government agencies running the new "open source" software and stole President Correa's data.

The hacker was immediately arrested and imprisoned. But... President Correa ordered the hacker released, and ordered the stolen information to be made public ("What's wrong with citizens knowing their president's information?" he reasoned). This still left a dilemma, though, since the Ecuadorian public clearly was not being properly served...

Enter (drum roll)............ Open Source Java!

In a partnership with an Ecuadorian company, Colorado's Savoir Technologies was engaged to fulfill the vision President Correa had boldly announced back in 2007. Sending in an army of two developers in the fall of 2012, in a period six months the Savoir team built a secure, fault-tolerant, scalable, distributed system whereby Ecuador's tens of millions of citizens could log into government web sites using their Cedula (a government ID number), and access their records from a dozen or more different Ecuadorian government agencies.

The technologies include Liferay, many components of the Apache stack (Cassandra features prominently, Camel, and much more), plus JAX-RS, JAXB, et al... The strategy is to isolate the unchangeable legacy components from each agency from the broader, secure, fault-tolerant, Java-based web and routing tiers, and interact with those legacy components using a custom adaptor. That is, each legacy system is treated as just another data source, which has its own peculiar, non-standard interface structures. Since these legacy systems are unreliable, Cassandra maintains the latest successfully retrieved information, which is used to fulfill requests when the actual legacy system is unavailable.

Books were given away at the session for asking good questions. Unfortunately, I was too completely engaged with typing notes and thinking about the innovative scalability and failover strategies Savoir implemented, to be able to think of a question before all the books had been given away! Those notes will be composed into a future post that relates some of the technical details of what Savoir accomplished in Ecuador.

The system has been up and running for about six months now, with high 9's availability, and two successful live rolling deployments of software upgrades. Other South American nations have taken notice, and are considering the same type of upgrade to their own government systems.

Ah, to be an Ecadorian today! Or a future Chilean, or Columbian, or Peruvian, or ...

And, did I mention, it took an army of onlytwo Java developers working for about 6 months to correct and upgrade unreliable and insecure systems that had plagued tens of millions of Ecuadorian citizens for decades under a peculiar historic mix of legacy technologies and "open source" Microsoft technologies??? It all runs on commodity PCs, as well, no fancy hardware...

Yeah, open source Java software's OK, isn't it?

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed.

-- Kevin Farnham (@kevin_farnham)

At the JavaOne 2013 Java Technical Keynote, there was a series of demos of software that enables two people to play chess, using some of Java's latest features, including Java EE 7 Websockets, many variations of Java 8 (recent weekly builds), Lambda Expressions, Java ME, Embedded Java, ... It was an impressive demo of many of Java's recently-released and not-yet-finally-released capabilities, which included the introduction of the DukePad, a home built tablet powered by a Raspberry Pi (cost of the components: about $300 US).

We saw the game played on various clients, including a seemingly not that powerful iOS tablet device, the DukePad, a modern laptop (with very fancy animated Dukes being the chess pieces), and a Raspberry-powered robot...

No, you're not misreading that, and I didn't mistype it. The final client for the app was a robotic arm, powered by a Raspberry Pi that was interfaced back to the exact same Java EE 7 server software that was used for all the other clients... This robotic arm responded to commands issued by the Raspberry Pi in response to the same JSON messages that all the other clients received.

An example JSON message instructing the client to move a piece identifies which color to move (white or black), the starting location of the piece, and the ending location of the piece. The locations are identified using chess algebraic notation:

The robotic arm is moved using a set of servomotors, motors that can be commanded to rotate to a specified angular location (including multiple revolutions). I did lots of work with servomotors more than 30 years ago, using a software and hardware setup that, at the time, cost hundreds of thousands of dollars!

But, I assure you, the robot constructed for the chess client demoed today at the Java Technical Keynote did not cost in the 6 digits of US Dollars! For example, the Raspberry Pi costs about $30, while the HP 9845s I was working on cost upwards of $30,000 back when I was programming what in essence were servomotor-powered robots...

Anyway, when a piece is to be moved to an unoccupied board location, the robotic arm (which is equipped with a clasping 'hand'), opens the hand, moves down over the piece, closes the hand about the piece, lifts the piece to an altitude above all the other pieces, moves to the new location, sets the piece down, unclasps its hand, and lifts away from the board.

Actually, that probably leaves you with an incomplete vision of this robotic arm. It actually has two hands, each located at the end of a rotatable lever that is pinned to the arm at its midpoint. Two hands are more convenient than one when you need to hold two objects simultaneously, right? And it's very convenient if you can do that when one chess piece conquers another. In this case, the arm picks up the piece that is moving, then flips that hand upward and flips its empty hand down. The empty hand picks up the piece that was conquered, then flips the conquering piece down onto the chess board position. After this, the conquered piece is placed somewhere off the board (I didn't notice where).

Cool, right?

"No!" you shout. "Who cares? How does this matter?"

I'll get into the answer to this question in more depth in subsequent posts. But first, remember my statement that 30+ years ago I was programming software for what was in essence a much simpler robot using equipment that cost hundreds of thousands of dollars? That software controlled but a single servomotor, using a $30,000+ scientific desktop computer that was controlling a GPIB interface (which itself cost beyond $1000, if I remember correctly).

So, cost-wise, we've reduced the expense of making a simple servo-controlled robot by somewhere between 1000 and 10000 times. And that's not even counting 30+ years of currency inflation. The hardware I worked on cost many, many multiples of my annual salary back then!

Now factor in time: it took me perhaps a year of programming (in HP's Rocky Mountain Basic, or RM-BASIC) to develop that simple, quite expensive robot, and a simple user text-based user interface with an X-Y plot. The time to program the robotic chess client was likely some weeks, I'd guess (and I believe this was indeed suggested by the demo team). So, you've reduced the software engineering time by a factor of, say (being conservative) 10.

Let's do the math:

[hardware cost reduced by a factor of 1000+ (3-4 orders of magnitude)]

Multiplied by

[software development time reduced by a factor of 10+ (1+ orders of magnitude)]

What's the answer?

My answer is: if you don't see a world-changing technology revolution in the making here, then... well... you're just plain not seeing the same tomorrow I'm seeing. So far, anyway...

But, there are still four more days of JavaOne to go!

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed.

-- Kevin Farnham (@kevin_farnham)

Looking Forward to JavaOne Sunday: JUG Forums, NetBeans Day, GlassFish, Technical Keynotes, Duke's Choice Awards

It used to be that Sunday was a fairly relaxing day for most. Not anymore! This year, Sunday is already overcrowded with many more events and sessions than one can possibly attend, as the JavaOne 2013 Content Catalog Sunday entries demonstrate.

Sunday's activity can be divided into five categories:

  • Java User Group Forums, a set of technical sessions covering the Java platform, organizing and growing user groups, and interaction with and participation in the JCP;
  • NetBeans Community Day, which starts out with a celebration of NetBeans's 15th anniversary, before moving on to a series of panel discussions on the diverse applications to which you can apply NetBeans;
  • GlassFish Community Day, featuring the GlassFish roadmap, an executive panel, and customer stories;
  • the Java Strategy and Technical Keynotes, laying out the vision for Java's future (and often including some surprise announcements);
  • finally, the day's formal events end with the Taylor Street Open House, where the 2013 Duke's Choice Award winners will be announced (here are last year's winners).

So, it's a pretty non-stop day -- including for James Gosling, who will be participating in several NetBeans Day sessions. More later...

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed.

-- Kevin Farnham (@kevin_farnham)

I've finally found time to start browsing the JavaOne 2013 Content Catalog, andand various summaries of interesting JavaOne sessions organized by topic (you can see several of these on the home page right now). Thanks to Terrence Barr's "JavaOne 2013: Deep into Embedded" post, I came across Controlling NAO Robot with Java [CON11839]. The session is presented by Dimitri Merejkowsky, Software Engineer at Aldebaran Robotics.

Here's the session description:

NAO is a state-of-the-art humanoid robot with 25 degrees of freedom. With a brand-new SDK allowing easier integration, you'll discover how simple it is to use Java to control NAO robot and create apps.

After a quick search, I found this video of NAO in action:


I'm hoping to be in attendance for this one: Thursday, September 26, 2-3 pm, Hotel Nikko - Monterey I/II.

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed.

-- Kevin Farnham (@kevin_farnham)

Since JavaOne is almost upon us, our recent polls have asked the community about the conference and about Java conferences in general. In the last-completed poll, the community was asked to identify the most important track at this year's JavaOne. Meanwhile, our current poll asks what the best part of Java conferences is.

A total of 304 votes were cast in the JavaOne tracks poll. The exact question and results were:

The most important track at JavaOne 2013 will be:

  • 30% (90 votes) - Client and Embedded Development with JavaFX
  • 7% (22 votes) - Core Java Platform
  • 3% (9 votes) - Edge Computing with Java in Embedded, Smart Card, and IoT Applications
  • 7% (20 votes) - Emerging Languages on the Java Virtual Machine
  • 16% (50 votes) - Securing Java
  • 4% (12 votes) - Java Development Tools and Techniques
  • 7% (20 votes) - Java EE Web Profile and Platform Technologies
  • 6% (17 votes) - Java Web Services and the Cloud
  • 21% (64 votes) - It's all important!

I wondered if it was going to end up being a mistake to add the "It's all important!" option -- would a lot of people just bail out from making a decision and select that choice? But, no, that didn't really happen. So, it's clear that voters took some time to think about their choices, and selected the track they really believe to be most important.

With eight tracks in the conference, the process of selecting a single "most important" track is a bit daunting. The work most Java developers do surely spans multiple of the JavaOne tracks. Still, the results of this (unscientific, the standard caveat) poll offer a few interesting items to note.

For example, the JavaFX track received a plurality of the votes -- not only beating "It's all important!", but considerably outdistancing (almost doubling) the second place track, "Securing Java." Among other things, this suggests that the tide is really beginning to turn for JavaFX. While in our recent JavaFX poll, 85% of the voters said they had not done any JavaFX development yet, it seems that as each JavaFX deficit is fixed (for example, adding support for additional operating systems, etc.), interest in JavaFX increases. Certainly, the world is changing so fast that it's difficult for a new client technology to enjoy massive gains in the share of applications that utilize it -- but, it is interesting that this track was the clear winner in this poll.

Security in Java has been so much in the news this year that it's not that surprising for "Securing Java" to receive a significant share of the vote.

It's a bit surprising to me that "Edge Computing with Java in Embedded, Smart Card, and IoT Applications" received the lowest share of the vote, given that embedded technology and the "Internet of Things" have received so much attention at recent conferences, including sub-conferences at both last year's JavaOne and this year's Jfokus. I have pretty much zero doubt that the Internet of Things is going to be totally transformative in the coming decades. I say this in part because it so reminds me of the work I did early in my career, in the late 1970s and early 1980s, when desktop computers were fairly new, and began to transform the world.

Also surprising to me is the relatively low vote total for "Java Web Services and the Cloud." But, perhaps there were just too many choices. And "It's all important!" was really a vote by 21% of the voters for all eight tracks...

New poll: What's best about Java conferences

Our current poll asks you to respond to: The best part of Java conferences is.... Voting will be open until Friday, September 20, just a couple days before JavaOne.

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed.

-- Kevin Farnham (@kevin_farnham)


Linda van der Pal has been a developer since 2002, visiting many conferences to gather and share knowledge. In 2006, she founded Duchess, a network for women interested in Java. She is now a member of the board of the Dutch chapter, along with R

JavaOne 2013 is almost here, but the community theme phrase still hasn't been selected. You can have a say in this by voting for one of the 10 final contenders in the JavaOne 2013 Community Theme poll. Click the link to vote, or just go to the home page and vote there.

Voting will end midnight, September 8, Sunday (US Pacific time).

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed.

-- Kevin Farnham (@kevin_farnham)

Filter Blog

By date: