1 2 3 Previous Next


186 posts

There appears to be over-reacting and fearism concerning a recent decision to cancel the DLJ project, and subsequently Ubuntu's plan to remove DLJ-based Java packages from their repository.  I'm totally out of the loop of this except for a couple things.  As the former DLJ Project Lead I was still vaguely involved with the management of that project, and recently there was an email exchange between myself, Dalibor and Tom where we decided it would be best to just shut down the DLJ because the OpenJDK had proceeded far enough that the DLJ was simply unnecessary.

Some blog postings on osnews.com and www.omgubuntu.co.uk came to my attention where there are many comments along the lines of "OMG THE SKY IS FALLING AND ORACLE IS EVIL".  Well, sigh. 

There's nothing to worry about here.  It's really very simple.

The DLJ Project was launched at JavaOne 2006 when it looked unlikely that Sun's Java implementation would ever be open sourced, we devised the DLJ Project to provide JDK bundles under a liberal license.  It was meant to help the community easily have a good quality Java implementation on Linux, but then the new CEO declared the creation of the OpenJDK project from the stage of that very same JavaOne.  

Over the course of time the OpenJDK project became really good and it was no longer necessary to maintain the DLJ project.

There's nothing EVIL here .. it's simply that the DLJ project became irrelevant.

Dalibor had a nice post about this a few months ago - http://robilad.livejournal.com/90792.html

Hey, it's been awhile since I last posted on this blog, largely because I didn't have much to say about Java for awhile, and partly because I've been working with Node.js over the last year.  It's a new software platform that I think the Java community needs to know about, and as the author of a book about Node (a.k.a. Node.js) I may be the person to explain a thing or two to y'all.  Since it's been so long since my last post here, a bit of re-introduction should be useful.  I'd spent 10 1/2 years working for Sun in the Java SE team, as an "architect" of the Software Quality Engineering team (SQE).  I was also someone who had some interesting ideas to share about Java (hence this blog).  Well, I hope they were interesting.  During that time, I was privileged to meet the FreeJava community (classpath, harmony, etc), participating in launching the OpenJDK project, the JDK-Distros project, the Mustang Regressions contest, and some other interesting projects.  It was an amazing time of meeting the broader Java community.  But 2.5 yrs ago things changed (ahem) and I stopped being active with Java and didn't want to post here because I wasn't sure I had anything to say.  Until now, when I feel a need to talk about Node.

Node (a.k.a. Node.js) is a new software development platform where the main talking points are:-

  • Server-side JavaScript executing on a fast JavaScript virtual machine (Chrome's V8)
  • Asynchronous execution model that's claimed to be light-weight and highly scalable
  • A no-threads mantra that synergistically works with the asynchronous model to make each connection low cost for high scalability
  • Excellent network I/O event handling event dispatching asynchronous runtime library that makes it amazing easy to develop succinctly implemented server software
  • Growing ecosystem of add-on modules and web frameworks and more
  • Excellent module system and package management system; cures dependency hell

Node's "hello world" is a 6 line script that also implements an HTTP web server.

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
}).listen(1337, "");
console.log('Server running at');

While most of the attention is on Node as a means to implement server applications, that's not all.  It's a general purpose programming platform akin to the Perl or Python or Tcl or Java model of use.  That is, you write your code and rather than compile it to object code it's run with an execution engine.  The Node execution engine is Chrome's V8 virtual machine wrapped with the layers that make Node what it is - namely the core runtime packages which come baked into the executable.

Okay, great.  What does that mean and how to contrast it with Java? 

One thing that leapt to mind early on was the old dream of the same language on both client and server side.  This dream perhaps dates back to the early days of Java, where Applets were to be how we'd implement dynamic stuff in a browser, and Servlets would be how we'd do it on the server.  The same language on both client and server could/should/would/maybe give us some goodness.  Who knows, but something in that dream failed along the way and we ended up with JavaScript in the browser and various languages on the server.  With Node we have a new chance for this dream to occur, but this time the language is JavaScript and in the browser JavaScript+DOM and asynchronous requests have given us some amazing web experiences.  Maybe we'll be able to write JavaScript code which could execute either in the browser or on the server depending on some conditions, or maybe not.  But having the same language at both sides should make it easier for different implementation teams to communicate and work closely together.

I think an area where Node can shine extremely well is in implementing the real time web.  Okay, sure, Twitter implemented their real time web with Ruby and Scala, but they started on that before Node existed.  I base my thinking in part on some 2006 blog posts that led to the COMET protocol, and in part the architectural choices in the Node platform. 

Those 2006 blog posts described problems with thread-based architectures when there are 10's of thousands of connections to a single web server.  Why that many?  Because the goal was for websites to be asynchronously popping messages onto screens and doing various other things which required holding a connection open to each web browser for a long time.  Think Facebook and their ability to tell you that so-and-so liked something you posted earlier, that's implemented with a long running connection over which messages are sent. 

In a thread-based system the overhead of one thread per connection means a server can't scale to very many connections, resource utilization is low and you're having to buy excess servers to get the job done, which cooks the planet because of too much electricity consumed to drive the Internet.  The 2006 COMET blog posts described a different asynchronous architecture that removes overhead implementing the real time web more efficiently for better resource utilization.  Okay, I hope I'm characterizing those posts correctly.

In any case those posts discuss implementing this in Java - Java's nio package lets you implement asynchronous I/O and Java is a powerful platform.  It begs the question, why do I think Node is great for the real time web, and why didn't Node's authors (especially Ryan Dahl) use Java as its foundation rather than JavaScript.

I don't know why Ryan Dahl didn't do Node with Java but instead used V8.  I did read all his blog posts and know he was really interested in high performance web service development along the lines of those COMET blog posts.  He was also hot on"no threads" because threads incurmemory/CPU/complexity overhead.   What I can say is that JavaScript is highly suited to this task, in a way that Java is very clunky at.

What I mean is that closures (anonymous functions) come baked into JavaScript and are routinely used for event handling.  I don't know diddly about the technical definition of closures, but can say that anonymous functions are quite fun to use for writing what's essentially a Listener function.

In Java implementing an event handler is done by defining a Listener interface class, then importing that interface, implementing a subclass of the interface, and filling in one or more functions with your business logic.  Along the way you have to dot every i and cross every t with correct type signatures.  Isn't it tiring just listening to how this is done?

In JavaScript an event handler is as simple as "function(arg, list) { code .. }" .. no muss .. no fuss .. quite easy and fun.

It's possible to rathole down a discussion of dynamic typing versus rigid static typing ... I don't want to go there.  If you look in the back history of my blog posts on java.net I think you'll find me arguing the other side, that we have to have rigid static typing to help us steer clear of broken code.  I can say that this dynamic coding methodology is a heck of a lot of fun, and wish my former "rigid static typing" self would just get over it. 

Something that helps a lot is Node's excellent module system.  Modules themselves are pretty straight-forward.  The design was borrowed from CommonJS and implements a strong encapsulation around each module.  The code that's internal to a module simply cannot be reached from outside the module, and you export explicitly the functions you want to expose.

What makes it excellent is the algorithm for finding modules.  It's flexible enough that an application could have within its code tree several different versions of the same module, to allow fine grained dependency resolution.

Because HTTP is a built in core module it's amazingly simple to write REST-based server (or client) applications with Node.  The "req" and "res" objects shown in the hello world above abstract the HTTP protocol conversation.  All a service function does is fill in data in the res object, add data to the body, and that's it.  The HTTP object takes care of serializing the data down to the HTTP protocol for you.

In my book, Node Web Development, I was able to demonstrate in 6 pages refactoring a web application to move a heavy computation to a back end server using a REST service.  That 6 pages included a REST server, a small client application to test the back end server, and to refactor the application to use the REST server.  Six pages.  To me that demonstrates the power and flexibility of Node because of how easy it was to do all that.

This post has gotten a little long in the tooth, so I want to draw it to a close.  I hope y'all found it useful.  I've been working with Node for almost a year and the whole time in the back of my mind I was going on and on comparing back and forth between Java and Node and... Node is freeing JavaScript from being trapped in the browser, and letting it shine in a new place.  Yes, I know about the largely unknown history of server-side-javascript, but SSJS has had very little impact on computing and JavaScript has become synonymous with client side programming.  Node is the first serious outing of SSJS and it's a platform with great potential.  If you want to follow my adventure with Node head over to http://nodejs.davidherron.comand look for my book as well.

 Last week Apple released their latest product destined to change the world (the iPad).  At least that's what they want us to believe.  Perhaps the biggest controversy over the thing is the lack of Flash capability.  However this being java.net I have to wonder out loud, where is Java capability, and more importantly why isn't as much controversy being raised over Java being missing? But I think we all can enumerate some reasons for both being missing.  And it's worth it for the Java community to ponder this issue.

A couple weeks ago I attended a meeting of the Silicon Valley Web JUG (yes: Java User Group).  (The Future of the Web According to Dion Almaer and Ben Galbraith)  A very interesting meeting with a great overview of advances in HTML5 with an eye on the great possibilities it holds.

The interesting thing is they began the evening with a question:  How many of you are interested in JavaFX?  A meeting of 100+ geeks in Silicon Valley who are associated with a Java User Group, you'd think a few of them would be interested in JavaFX.  One person raised their hand.  I think that says a LOT.

Their presentation said a LOT about why Java and Flash both are missing from the iPad and iPod, and why we shouldn't care about that functionality gap, and indeed should feel liberated at their absence.

The key is web components built using standardized web technologies (a.k.a. The Open Web).  That's HTML, XML, HTTP, JavaScript and that ilk.  Flash, not being standardized by anybody, is not part of the Open Web.  Despite Java having a standards body behind it and being treated/delivered by Sun as an Open Standard, it was never accepted by the tech/web community as part of the Open Web.  And.. uh.. JavaFX.. sheesh, that's nowhere near being treated/delivered by Sun as any kind of Open Standard, instead it's being treated as a proprietary product where Sun is the big gorilla.  Oh, wait, that's Oracle now.  Sigh.  In any case the Open Web should most certainly ignore JavaFX just like it calls for Flash to be eschewed.

By being based on Open Standards the Open Web has tooling available from many organizations and a rich ecosystem of experience and adoption.  

An issue traditionally with HTML+JavaScript was speed.  Javascript has historically been an interpreted only language and anybody who tried Java 1.0 knows how glacial that can be.  Lately some Javascript implementations have been developing JIT and bytecode interpretation capabilities that eerily echo the development of Java virtual machines.  According to Ben Galbraith some of those teams are staffed with former Java VM developers.  In any case it means faster HTML+JavaScript execution with more capability to provide a rich GUI experience using just HTML+JavaScript.  (FWIW I'm typing this in Google's Chrome browser)

This ain't the HTML+JavaScript of yesteryear.  This is a brave new world.  It seems in retrospect the promise of Flash and Java was speedier UI experience than the HTML+JavaScript of yesteryear, and that if the HTML+JavaScript of the future is good enough, then both Flash and Java will be rendered irrelevant.  Yes, sure, of course both Adobe and Sun have over a decade of virtual machine implementation experience.  But neither can achieve the tight browser integration that JavaScript can.

HTML vs. Flash: Can a turf war be avoided? That's an interesting article covering the current stance where Adobe is saying "HEY WAIT A MINNIT" about the lack of Flash in the iPad.  e.g. "We are now on the verge of delivering Flash Player 10.1 for smartphones with all but one of the top manufacturers," Lynch said, specifically mentioning the Nexus One as one such device and adding that the software also works on tablets, Netbooks, and Net-enabled TVs. "Flash in the browser provides a competitive advantage to these devices because it will enable their customers to browse the whole Web...We are ready to enable Flash in the browser on these devices if and when Apple chooses to allow that for its users, but to date we have not had the required cooperation from Apple to make this happen." I happen to know for certain that Sun could say the very same thing about Java on iPhone/iPod/iPad.  

Where is the truth between these possible states:-

  • The Web only has components standardized by standards bodies
  • All the tools and components are completely open source under OSI approved licenses
  • There is a mix of open standardized components, semi-open proprietary components and completely closed components (todays situation) 
  • Every web site has its own incompatible standard (the fate we fortunately avoided several years ago)




(tangential digression

Open Source != Open Standard.  For a long time the hue and cry was for Sun to Open Source Java, and that would ensue a brave new era of wonderful harmony across the planet or some such.  In practice Sun didn't quite open source Java, instead it created an Open Source project on a specific implementation of Java (OpenJDK) but "Java" (in my mind) was explicitly not open sourced.  As a result while the resulting situation was much better than before the wonderful era of harmony did not ensue.

In any case an Open Standard can be delivered by closed source software so long as it obeys the standard.  An Open Standard still allows wide use of the software and a huge amount of freedom in lots of practical forms of freedom.  But Open Standards don't allow things like forking that Open Source explicitly allows.  

I'm drawing on several threads of thinking in several presentations and conversations this week at JavaOne, and am thinking the Java Community Process (JCP) no longer serves the needs of the Java ecosystem. I'm not the first to say this, not the last, but here's a few thoughts anyway. Sun (soon Oracle) is the owner and for the process to work out well the owner has to be enlightened enough to serve the needs of others as well as their own needs. In reaping rewards from building an ecosystem requires having the wisdom that your benefit comes from everybody happily using your ecosystem, and always acting to nurture the ecosystem you've built. Some styles of gardening (Permaculture) recognize this principle. However administrations change and while one set of people overseeing Java might be enlightened the next set might be money grubbing short sighted opportunists. I'm not pointing fingers at anybody, just outlining a general principle. The question is.. is it appropriate to have the foundational pieces of the Java ecosystem in the hands of one company? Or is it better for those foundational pieces to be in the hands of a consortium whose purpose is the benefit of all? Open process - When Java was first developed in the mid 90's the open source software world was nowhere as mature as it is today. In 1995 the open source software scene was very primitive even if some specific pieces of that scene were well developed and widely used. The JCP was born in that environment and historically has served mostly big business and mostly acted behind closed doors and secrecy. In todays world where the open source software scene is much more developed and accepted, is closed door secrecy of any use now? Of course the JCP has been undergoing reforms, a good thing. Also a language specification, VM specification, etc, those are not open source software, they are specifications. The IETF is an example of a standards organization developing standards out in the open in a way I longingly remember from the early 90's when I was still an electronic mail expert. The JCP setup is tailored to the old model of iterating the Java platform. There is a platform JSR to define the Java <n+1> and a passle of specific JSR's for each feature in Java n+1 are formed to steer those features through the design and development process. This tied well with Sun's traditional 18 month or so development cycle of delivering a huge amount of change in 18-24 month cycles. Does that model still serve us? Or is there are model with shorter cycles which would serve us better? For that matter Sun has been successfully delivering feature changes in the "6 update" train, going against their former rules of not adding features in update releases. (updates were only for bug fixes) Having short cycles offers a lot of potential benefits. Witness what the Ubuntu, Fedora, etc projects have been able to do with short cycles. It means rapid adjustment of direction with changing conditions. It means a bug fix has a greater chance of getting into the platform than previously. etc.  
The JavaOne opening keynote is still a fancy rock & roll show with fancy stage and the like. It's always exciting to see what they have to say, and they do a good job of spinning a story that Java is Everywhere. The overall message is to convince developers that the Java platform is compelling, that Sun is providing this compelling ecosystem for developing applications, and that the developers can become uber-rich by developing applications for the Java platform. It's a cool message.. Anyway it struck me how non-community-oriented this message is. It's delivered in a push model, that "we Sun are developing this platform for you <the developer>" rather than a community oriented message of "we came up with this cool thing, let's work together to make it totally great". At one point Jonathan said something about delivering compelling technologies that engage developers who are going to build the next eBay. This phrase "the next eBay" is emblematic of a problem Sun has in general, in that they develop lots of great technologies not all of which are lines of business that can do $1B per year. Sun's management however can only contemplate billion dollar business decisions and is incapable of working with smaller scale business decisions. Example in point: SunSpot which is going to remain an unexploited business opportunity because it's too small. Sun is leaving a lot of $$$'s on the table by being unable to exploit small business units along with the large ones. In any case I want to get back to this distinction between the push model of developing technology to give to developers, versus setting up collaboration projects to develop technology ideas. This is important in regard to the trending at Sun towards Open Source software projects. While the official definitions of open source projects focus on the licensing terms and freedoms granted by the license, it's widely recognized that community oriented development is a requirement for success in open source software projects. There are a lot of resources out there with guidelines for successful communities and how it exists within open source software projects. Yesterday @ CommunityOne the Ubuntu community manager, Jono Bacon, gave an excellent presentation on community (artofcommunityonline.org), for example. Basically a community is a cluster of people interacting with one another. It help's bring community into existence when the people gain value of some kind from participating in community processes. It seems obvious to me the push model of delivering technology does not lead to community creation. The push model isn't very collaborative, not engaging people into interaction. How can the community form if there is not a compelling reason for people to interact with one another? Perhaps this is a core reason behind a number of WTF issues related to Sun and Java .. Sun makes excellent technologies like Java, so why hasn't Sun been able to be successful as a business. During the Keynote the tail end was led by the new overlord, Larry Ellison. There was a little dance on the stage which wasn't explained but reminded me of the 2006 JavaOne keynote which was Jonathan's first time as CEO giving the keynote. He and Scott were on stage and they explained that the widget used by the presentation leader to control the slides, that the official name for that widget was "The Pickle". They made a big hooraw about Scott handing The Pickle to Jonathan in a symbolic passing of the torch of authority from Scott to Jonathan. During this keynote there was a similar passing of the Pickle. It went first from Jonathan to Scott who did a bit of joking around about reasons why Sun+Oracle makes sense, and then Scott passed it to Larry. During this section Larry & Scott addressed the obvious concerns we might be having about the Sun+Oracle deal and specifically what it means for Java. It sounds good in that for example Oracle's middleware is 100% Java. Oracle's product line-up is a database engine plus a whole big slew of apps running on top of the database, all of which are written in Java. It's clear that Java is important to Oracle. What isn't clear is whether the OpenJDK community is important to Oracle. Nowhere in Larry's talk did he mention open source, community, OpenJDK, etc. Instead he talked in this same push model. Larry also said a few oddball things ... He's been meeting with various teams within Sun to discuss product plans. This makes perfect sense in that Oracle buying Sun is clearly going to mean a direction change for what has been Sun's product line. A specific weirdo thing he said is he hopes for "JavaFX Libraries from the OpenOffice team". Uh... say what? I've long been wanting that very thing. It makes perfect sense to me that an Applet to display OpenOffice documents would be extremely useful. And with JavaFX it's very plausible this could be a great user experience. This would be known as Rich Enterprise App's. Rich applications need not be limited to consumer app's. There are plenty of examples of needing Rich applications for other purposes than immersive gaming. An obvious example is finance.yahoo.com and the like where stock information is presented as a fancy charting application. It's nice that Oracle sees the need for Rich Enterprise app's. However a couple years ago I had a chance to talk with a Marketing leader within the OpenOffice team, and brought up this very idea. That led to an interesting conversation. Because of the OpenOffice architecture any display app to show an OpenOffice document would end up dragging in pretty much every OpenOffice component. OpenOffice's file format is a compressed ZIP file with XML files in a known/standard ODF format. This is why it seems compellingly possible that an applet could simply read the XML files and render them. But OpenOffice has an embeddable object module so that e.g. you can embed a spreadsheet in a presentation to display charts or tables. Because of that any OpenOffice document can reference OpenOffice objects from any of the applications. Because of that even a simple viewer applet would be essentially the whole of OpenOffice. Another fly in the ointment here is the various licenses involved. One of the big huge values of OpenOffice is it's open source license that e.g. allows OpenOffice to be in Ubuntu/Debian Main and have equivalent status on other operating system distributions. But JavaFX is not using an open source license making it infeasible to put JavaFX into those operating systems. If OpenOffice were to be rewritten in JavaFX that would put a dependency on JavaFX making it impossible for OpenOffice to continue being delivered in open source operating system distributions. That is, if JavaFX continues being closed source. Maybe JavaFX will be fast tracked into being open sourced? An open question is whether Larry's statement means a demand to rewrite OpenOffice into Java/JavaFX .. or whether he only meant some kind of library. For example it might be possible to embed (JNI) OpenOffice native libraries as Java(FX) objects without biting the bullet of rewriting OpenOffice in Java. It would also be incredibly expensive to undertake an OpenOffice rewrite and also be very risky. In other words I was left scratching my head and going WTF is he thinking. Before you think I was turned off by the keynote, no, I wasn't. It was exciting the various ideas and things presented. For example they showed fabulous things with JavaFX TV, JavaFX BluRay, the new Authoring tool, and store.java.com. Very cool.  
Just a reminder to those of you a) attending JavaOne, b) interested in porting OpenJDK to other platforms, we have a BOF on thursday night. Please attend. The agenda is to simply bring the right people into the room and chat. Please attend.  
This session is conducted by a pair from SonyEricsson, and they're discussing Java based rich user interfaces for "mobile" devices. As always the word "mobile" is overly constrained to mean "cell phone" which is to me a misnomer because "mobile" could clearly mean other kinds of devices than cell phones. There are lots of portable electronics devices which would do well to have a light Java stack but for some reason the JavaME community focuses on cell phones only. What about digital cameras and portable game devices just to name two kinds of portable devices that are not targeted by JavaME. Rich UI requirements: Richer user experience is more compelling to user more likely to be bought by users. Users want their device to be theirs, their own colors, making it work the way they want. Operators need to brand the device. Usability enhancements possible with rich UI. JavaFX is a cross platform RIA stack, JavaFX Script is the language, JavaFX Mobile is for cell phones. "All the screens of your life" are defined as "Desktop", "Mobile" and "TV" (what about digital cameras?). JavaFX Mobile runs on top of Java ME. Same language, same API, for the core profile. Tools: Netbeans; JavaFX plugin for Illustrator and Photoshop (Production Suite) Capuchin: Bridge between JavaME and Flash Lite. Design UI in Flash with Java providing services. Combine two well known and widely spread technologies, Flash and Java. Capuchin API presented to joint MIDlet which contains both .swf content and MIDlet class(es). Flash can request from Java class, Java class can notify flash UI. "MXP" components provide services e.g. to access native services like calendar, accelerometer, contacts, etc, these components also available through relevant JSR's. To aid developers to expose an Java service, they have an API generator tool which helps generate MXP components. They did not create their own GUI authoring tool, because Adobe's Flash is a perfectly fine IDE. SWF2JAR. http://developer.sonyericcson.com Requires Adobe CS. There's an interesting strategy conundrum.. would it have been better for Sun to join forces with Flash Lite? Or is it better for Sun to attempt to own the whole stack with JavaFX. For the demo they show a "Car Shop" application developed in both JavaFX and using Capuchin. It shows you can use two different technology stacks to provide very similar applications. The reason I posed that strategy conundrum is due to the expense of developing JavaFX and to ask whether that expense was worthwhile. Why not instead collaborate with Adobe to provide rich UI experiences on mobile devices? Clearly Sun chose to develop JavaFX. Future? Sun's direction is clearly JavaFX and they decide JavaFX's direction. For Capuchin: SonyEricsson has 12+ devices now, also Symbian phones will have Capuchin. They will continue exposure of services, apparently promise to continue developing their stack. Their demo showed JavaFX can run on SonyEricsson phones.  

Blogging from JavaOne Blog

Posted by robogeek Jun 2, 2009
I am attending JavaOne and will be posting a series of blog's about each session I attend.  
So, hmm, Oracle+Sun. Interesting twist from the IBM+Sun matchup earlier. There has been numerous rumors over the years about SUN+xyzzy mergers such as Fujitsu, IBM, SGI, Apple, etc. And it's finally come to Oracle. It seems there's a lot of scratching of heads over what this will mean for the open source software projects run by Sun, and of course the back of my mind has been pondering the effect on the OpenJDK. An article in that esteemed dumpster diver rag, The Register, is prompting me to write: Oracle suits to strap on Sun's Java sandals: leader without followersThere's a meme in that article that's been in my mind a lot, especially with Stephen Colbourne's series of articles dissecting the JCP. Maybe the JCP doesn't properly represent what the community wants regarding Java. Many in the community regard Sun as the "steward of Java" and there are many questions over whether Sun is a good steward over Java. But does Sun think of itself as the "steward of Java" ?? As an employee inside the Java SE team I heard different statements from different people. Sometimes we were positioned as Stewards, other times we were positioned as Owners. The role of a Steward is different than the role of an Owner, right? Sun's true vision of its role in the Java ecosystem is what flavored what Sun did for/to that ecosystem. Similarly Oracle will soon (?likely?) finish the purchase of Sun and then it will betheir vision of their role in the Java ecosystem that will flavor what they do for/to that ecosystem. Some of the criticism of Sun was not properly monetizing its software, such as Java. But would a Steward monetize fully? Or would they hold back for the good of the community? Is full monetization is something an Owner would do? Think: Microsoft and Windows and programmers tools for Windows. The big 8,000,000 lb gorilla in programmers tools for Windows is, so far as I know, Microsoft. But monetization is only part of Owner versus Steward. Another part is feature choice, right? I never got involved with the EE end of the Java universe, so I'll trust The Register article when it says most of the focus of Enterprise Java developers is not the EE stack but the various smaller scale open source frameworks and tools. Hibernate, Spring, Maven, etc. This says to me that at the EE end the community is not developing the preferred technology through the JCP but through other mechanisms (primarily open source projects). That points to a failure of the JCP to properly represent what the community really wants. That touches on concerns I've had for a long time. The decision making for Java SE, as I saw it occur, seemed focused on satisfying the needs of huge organizations over smaller ones. I always heard it stated as these huge organizations are big customers of Sun, buying lots of Sun hardware/services etc, and of course we should pay attention to their needs. Similarly it's well known that the JCP is run by the Executive Committees, and that the EC seat's are predominately held by corporate JCP members rather than individuals. Does Java exist to enrich its owners? Or does Java exist to enrich us all? Who is to be making the decisions about the Java ecosystem? Sun employees were the inventor of Java and that means (because software is a work-for-hirearrangement) that Sun has had the right choose how Java is delivered to the market, and what to do with this thing. For better or worse Sun's positioning of Java was as an open playing field for everybody to partake in (Sun==Steward). Maybe Sun's true vision is Sun==Owner and that distinction may be the source of much of the friction in the Java ecosystem. What Oracle do we consult to learn what Oracle's vision is? And if the JCP truly doesn't serve our needs perhaps it needs to be killed, but what would or should replace it? Does it serve us best for significant pieces of the Java ecosystem to continue being developed outside a shared standards process? Or does the existing open source projects better serve the shared needs of the Java ecosystem? And should the core pieces of the Java ecosystem, the ME/SE/EE stacks, also be defined via open source projects rather than the closed source style of the JCP? Unfortunately we in the Java ecosystem/community cannot make some of the required choices, as they rest with the corporate overlords.  
I've been gone from Sun for a little while now but of course I'm still interested in Java, and thankfully still have access to this java.net blog. Anyway the recent news about IBM pondering buying Sun has piqued my interest. To me the potential hookup seems like a bad idea. Sun plays a useful role in the computer industry as an independent company, that would be lost if woven into IBM. And the tremendous overlap between Sun+IBM leaves me scratching my head over what they could be thinking. Unfortunately Sun has run into some more serious trouble than they were already in. Whatever the business stuff is being done.. the real puzzle is whether IBM will be a better steward of Java than Sun has been. I really don't know.. Wonder what is on everybody's mind. Here's a few items I'm finding in recent blog/news searches.. Dana Blankenhorn talks about The failure of McNealy's ponytail strategy .. the enterprise storage forum thinks IBM-Sun Merger Appears Near (with an announcement on monday) .. In JavaWorld they interviewed a bunch of folk about If IBM owns Java ... James Gosling is quoted warning of James Gosling warns of
I'm listening to the 'holidays 2008ish' episode of Javaposse and in reviewing their last years predictions they have enough fumbling around the status of OpenJDK that I want to do a little bit of explaining. 

OpenJDK 6 != JDK 6

There are circuitous historical reasons for this but the fact is that OpenJDK 6, as good as it is, does not correspond to JDK 6uN for any value of N. OpenJDK 6 began as a fork of OpenJDK 7, and the team stripped out code from the OpenJDK 7 fork until it became compatible with the Java6 specification as verified by the JCK 6 test suite. Joe Darcy has posted several blogs about this OpenJDK 6 Genealogy, OpenJDK 6 and 6u10 features, OpenJDK 6: Logistics of Partial Merge with 6u10, and the most important of these is: Forward to the Past: Toward OpenJDK 6 If you're scratching your head going "huh??", well, I don't blame you, just read Joe Darcy's blog postings and it will be clear as, well, uh, I just hope it's clear why. The bottom line is that OpenJDK 6 works rather well, several Linux distros are using it as their JDK, it can be built to pass the JCK6b test suite, meaning OpenJDK 6 can be used to build a compliant JDK, and unfortunately it is this evolutionary sidetrack which we hope will be relatively short-lived. It serves a purpose, namely of having an fully open OpenJDK compliant with Java6 .... 

OpenJDK ~=~ IcedTea

It seems some people really like typing "./configure" rather than setting up environment variables and running "make". The IcedTea project originally began due to incompleteness in the OpenJDK (gaps due to encumbrances) and the community requirement of a fully open source toolchain and code base. IcedTea has long been a set of patches applied to OpenJDK, along with a different build system that is "./configure" based as I just said. In OpenJDK we've replaced the encumbered code such that there are no gaps any longer. As we've done so I believe the IcedTea project has shrunken the number of patches they use. One nice thing seems to be that the IcedTea configure script makes it easy to build OpenJDK in many different modes such as using the Zero Assembler port to support compiling on non-x86/sparc chipsets, etc. A big piece IcedTea provides is a plugin/java-web-start infrastructure. We haven't been able to open source our plugin and of course for 6u10 we completely rewrote the plugin. It is hoped we will open source the new plugin into the OpenJDK project but to my knowledge that decision has not been made concrete set in stone. I don't spend much of my time looking at IcedTea so don't be alarmed if I've missed something ... 

OpenJDK 7 == JDK 7

Okay, given that there is not a Java7 JSR and all the JCP stuff related to that issue ... Hopefully all that will be straightened out and we do have a proper Java7 JSR, so for the following please assume that's the case, that Java7's JSR status is straightened out ... the plan is that beginning with OpenJDK7/JDK7 that the code bases will be nearly identical. It is obviously expensive to maintain a fork, and if JDK7 were to diverge strongly from OpenJDK7 it would do two things: a) be very expensive, b) undermine our efforts at an open source ecosystem. But "nearly identical" does mean it's likely there will be some differences. Remember those gaps due to encumbrances? Some of those gaps were simply code we couldn't open source as of May 2007 but have since done so, other gaps are for code we still have to gain approval on (e.g. SNMP), but there is some code where there are open source replacements where we still use the old closed source code. This is primarily in font and graphics rasterization. The old closed source rasterisation code, while being encumbered, has had 10+ years of bug fixing and fine tuning etc and, for any open source replacement to displace that code in productized JDK builds, it would have to be provably as fast and stable and good quality as the existing closed code. 

What took so long?

If we had followed normal release patterns JDK7 would be shipping about now. That is, Java6 shipped in December 2006 and our normal pattern is 18-24 months between major releases meaning the JDK7 launch would have been 2-5 months ago. What happened? Well, clearly there was a resource crunch on several angles. For example getting the nearly complete OpenJDK source release in May 2007 took a lot of effort from lots of people. But there was also certain announcements at JavaONE in May 2007 (a little thing named JavaFX) which also turned into a major rethink of Java (as some have said,this ain't yer Dad's Java) and also a major piece of work to accomplish. In other words instead of producing JDK7 we did JDK6u10 and JavaFX.  

I've been toying with doing a blog or podcast aggregator with JavaFX. I have a feeling that the strengths of JavaFX, animation, graphics, media, etc, could be put to good use in such an app. Additionally most podcasters put little player widgets on their site, and JavaFX could offer an alternative to the flash based player widgets. While that's the vision I'm chasing I'm nowhere near there, just yet.

I wanted to demonstrate first a few core bits.

I have a fair bit of experience writing feed aggregators in Groovy using the ROME library so of course for this JavaFX based tool I again turned to ROME. Maybe all feeds lead to ROME?

Because JavaFX fits into the Java ecosystem this means your rich media whizzbang RIA app can directly make use of the full breadth of Java libraries which are out there. ROME being just one of them. Take that Flash. ;-)

Referencing the ROME library is done in the familiar way

import com.sun.syndication.io.SyndFeedInput; import com.sun.syndication.io.XmlReader; import com.sun.syndication.feed.synd.SyndFeed; import com.sun.syndication.feed.synd.SyndEntryImpl; import com.sun.syndication.feed.synd.SyndEntry; import com.sun.syndication.feed.synd.SyndEnclosure;  Then to read in a feed into your program:- var inputter : SyndFeedInput = new SyndFeedInput(); var theurl : URL = null; var feed : SyndFeed = null; ... public function setFeed(url : String) : Void { setFeed(new URL(url)); } public function setFeed(url : URL) : Void { theurl = url; feed = inputter.build(new XmlReader(theurl)); ... } 

Other than the slightly different syntax this isn't terribly different than how code would be written in the Java version.

One unpleasant fact is that a) RSS/Atom feeds tend to contain HTML, b) JavaFX doesn't have a direct way to display HTML. There is a Text widget but it doesn't have a mode to display HTML. One could incorporate a Swing JTextArea configuring it for HTML but then the app would not be portable to a mobile device. Sooooo.... I suppose the last option is to strip out HTML codes before displaying it in the app. I haven't implemented this in my app yet as it's suboptimal but it's really the only choice.

The last thing I want to discuss here is a pragmatic about displaying the content of a feed. I'm still learning this language but the following appears to be the most convenient way of displaying the items in a feed in an app.

var items = Group { content: bind for (entry in feed.entries) { Text { x: 10 y: (indexof entry) * 20; content: bind entry.title } } } 

Unfortunately the ROME SyndFeed object is not conveniently implemented this way and a little bit of conversion is required.

Given a suitable definition of an Entry object

  public var entries : Entry[]; 

Then use this method for conversion

  function setupEntries() : Void { var list : Entry[]; var i : Integer = 0; for (entryy in feed.getEntries()) { var entry : SyndEntry = entryy as SyndEntry; var newentry : Entry = Entry { author: entry.getAuthor(), link: entry.getLink(), description: entry.getDescription().getValue(), enclosures: convertEnclosureList(entry.getEnclosures()), title: entry.getTitle(), date: entry.getPublishedDate().toString(), entry: entry }; insert newentry into list; } entries = list; } function convertEnclosureList(list : List) : Enclosure[] { var newlist : Enclosure[]; for (item in list) { var encl : SyndEnclosure = item as SyndEnclosure; insert Enclosure { type: encl.getType(), sURL: encl.getUrl(), encl: encl } into newlist; } return newlist; }

JavaFX 1.0 is launched Blog

Posted by robogeek Dec 4, 2008
You can view the updated site, launch videos, sample apps, and more, at javafx.com .. well .. when the server comes back up, it's having a little bit of trouble at this moment. Anyway, I want to post a few thoughts.. This is a big deal in some ways in that it is a radical departure from the past image Java has carried. Graphics and animation and media, oh my. Somewhere I heard this phrase This ain't yer dad's Java and it's accurate here. I've long thought if only we put as much attention into client Java as we have server Java that the whole thing would be in a whole 'nother league. We've finally done it, and I hope that we're not too late -- e.g. competitive marketing positioning could mean JavaFX fails to succeed due to nontechnical reasons.. So: 1.11 Will JavaFX be supported on Linux and Solaris? JavaFX 1.0 is supported on Windows and Mac OS X. Linux and Solaris support will be provided in a future release. Read into that what you will.Wei Qi Gao has a thing or two to say on this... and pushing pixels delves into the codecs A question that isn't on the FAQ is whether this thing will be open source, or not. Much as I want this to be open source that isn't how it stands, at the moment. Whether this means we're going back to old proprietary habits remains to be seen. Sun Frees Rich Internet Applications from Browsers, Releases JavaFX 1.0 - news coverage by JDJ.. and Sun Brews Up Rich JavaFX by 'technewsworld.com' ... and cote has some indepth coverage... and techpulse360 James Clarke has a little demo ... JavaFX - Inverting text color with a changing background. ... John O'Connor has a hint on installing JavaFX through netbeans ... basically, go into the plugin manager and request the javafx plugins to be installed. Couldn't be easier. Alan Zeichick asks JavaFX: Do we need another rich Internet platform?.. that's a real good question. Wish I knew the answer. For better or worse we've spent the time, money, resources and manpower to create this thing so we'd better make the best of it. I think there is potential for some advantage because of the cross platform nature of the thing. Further in my opinion if it were open source it could unleash a lot of latent development interest which could democratize availability of rich multimedia experiences (since Flash has a pretty firm lock-hold on the market for providing rich multimedia experiences through the web). Simon Brocklehurst has a different take ... that Applets could well be back! The bottom line is: even in 1.0 form, JavaFX looks good enough for us to evaluate for use in a real project where we don
Just in case you're not all election'd out, and just in case the recent election in the U.S. gave you some hope that things can change through elections, here's an opportunity to affect the direction of Java ME. JCP Java ME EC Election: Vote now for a Voice for Independent Developers by Terrence Barr is a good outline of circumstances related to the JCP and Java ME. The role of the JCP is to oversee and coordinate specifications related to Java technologies. As Terrence said "Fundamentally, the JCP is a very open organization" and a large portion of the JCP membership is made up of individuals. However the EC's, especially in Java ME, are dominated by industry heavyweights. While the industry heavyweights do have a reason to be at the table and represented in decisions regarding Java technology directions, so too is there a reason and need for individuals to be represented in those same decisions. For some things the viewpoint of the individual, rather than the industry heavyweight, is very important to have in the deliberations. Terrence makes a good case for Sean Sheedy, but since I don't know him I can't say whether or not Sean is a good choice. I do agree wholeheartedly that having individual independent developers represented in the JCP is vital for the JCP to be more representative of the whole of the Java ecosystem.  
The Sun Shows Signs of Life "After two-plus years of..generally eerie calm..sun is finally showing signs of life.."I think..minimum is behind us," says sun..statement is prompted by an October flurry.."This represents a real increase in .. activity."..Hathaway tamps down the excitement: "We're still years away from .. maximum and, in the meantime, .. sun is going to have some more quiet stretches." ..But it's a start. Stay tuned for .. activity.

Filter Blog

By date: