|
September 2007
September 21, 2007
Has Sun abandoned the JCP?
What would happen if Sun pulled out of the JCP? Do you remember seeing a JSR for JavaFX?
I've thought about this before: what if Sun decided the JCP wasn't working, and instead of trying to fix it, it just abandoned it altogether? One such example of this is the recent release of JavaFX Script, JavaFX Mobile, and JavaFX TV. Yes, they’re three different technologies really, but they are related, and they were announced together. Otherwise you could argue these are three recent examples instead of just one.
The Java Community Process does have some problems. For instance, a vendor can start a JSR, get it approved, and then just sit on it and prevent any progress from being made in that area. If this is an area related to that vendor’s business, there can be some benefit to doing this. For instance, the JCP states that once a JSR has been created for a certain feature, a second one cannot be created. Therefore, a vendor that has a lead in a niche area can prevent other key companies from competing in that space via a JSR. Of course, there’s nothing stopping that vendor from bringing a competing product to market, but they may be seen as circumventing the JCP and hence the Java community.
Also, voting for approval of a JSR should be based solely on the technical merits of the technology in question. However, some representatives use their vote to point out their dislikes for the company that sponsors the specification lead. We’ve seen this happen with JSR-316. It’s not unreasonable to consider one company withholding an approval just to voice its dislike for another company involved in the JSR.
The JCP becomes a political playground, where the technology itself can potentially be stifled – this is not what the JCP was intended for. But how do you fix it? That’s difficult to answer, and some believe there is no easy answer. Apparently, Sun might agree, as evidenced by the JSR-less JavaFX.
What’s your opinion of the Java Community Process? Does it work? Can it be fixed? Do you even consider it worth paying attention to? Let me know.
Happy coding,
EJB
Posted by Eric Bruno at 08:16 AM Permalink
|
September 17, 2007
Mock Deal: Dell Buys Sun
On sports shows, people often discuss mock baseball trades and debate whether they make sense. I propose a mock deal where Dell buys Sun.
If nothing else, the combination would be a little unusual. However, it's no more unusual than when Compaq bought DEC, is it? And Dell would get quite a bit out of the deal in terms of server market share. Currently, IBM and HP each own about 30% of the server market, while Dell and Sun combined own 22%. Alone, both of these companies are insignificant in the server market; together they become a true player.
The deal would certainly bolster Dell's server and storage hardware offerings. Add Sun's unique designs, such as Thumper and StorageTek hardware, along with its other 8-core Sparc-based (http://www.sun.com/processors/UltraSPARC-T1/), energy efficient, servers, and you infuse quite a bit of flavor to Dell's currently plain server line-up.
It also gives Dell the Solaris OS and the StarOffice software suite to gain leverage versus a Microsoft OS and Office-only software strategy. For Sun, it opens up sales channels that they haven't been able to crack; those that Dell has mastered over the years.
And most of all, it Dell would get Java, which can help them get back into a market they haven't been that successful at in the past - devices. New markets, such as cell phones, MP3 players, smart appliances, and automotive, for example, would be opened up to Dell with Java - its new secret sauce.
But this is only a mock deal, no more real than when callers discuss pretend baseball trades on a sports-talk radio show. Who knows if this would ever happen?
-EJB
Posted by Eric Bruno at 08:28 AM Permalink
|
September 14, 2007
Project Hamburg
The project formerly known as Consumer JRE, formerly known as Browser Edition, formerly known as the Java Kernel...
I say, let’s just use a symbol to identify this project - something from the wingdings font set, like “.” I think Sun has spent more time and effort on naming this thing than actually defining or marketing it. But nonetheless, it’s actually very cool technology, whatever you choose to call it - I’ll call it Project .
Project Hamburg (alright, I give in) is about making Java quicker, smaller, and easier to get up and running on a computer that doesn’t have it installed yet. This type of approach would have made Java Applets, for example, less of a burden as they required relatively huge downloads to install and run.
Here are the main items that the Java desktop team is shooting for in this release:
- Quickstarter. Radically reduce the startup time for Java applications and applets.
- Java Kernel. Reduce the time to install and launch when the user needs to install the JRE in order to run an application.
- Deployment toolkit. Enable easy detection and installation of the JRE.
- Installer improvements. Improve the user experience of installation; namely streamline, simplify, and speed up the installation process.
- Graphics performance on Microsoft Windows. Enable default graphics acceleration for simple and advanced 2D rendering.
- Nimbus look and feel. Release a new cross-platform look and feel based on Synth.
Happy coding!
EJB
Posted by Eric Bruno at 04:00 PM Permalink
|
September 07, 2007
iPhone vs. Google Phone
The Google Phone is rumored to be 100% Java-based, through and through. Contrast this to the iPhone, which is 100% anti-Java.
While the iPhone points to a scenario very much feared by Sun (where Ajax client apps replace the need for Java on mobile devices), Google is breathing new life into client-side Java. I blogged recently about how I would love to have a Java-based phone (where even the OS is written in Java) that has the ability to make VOIP calls when on a wireless network.
Couple this with Google’s rumored plans to build free coast-to-coast wireless networking, and this dream of mine may just come true. The advantages to Google, which were confirmed when Google licensed StarOffice from Sun, is that a Java-based phone provides freedom and flexibility in terms of the device used for the phone. Just as you can purchase a “white box” PC today and just install Windows on it, the same could hold true for mobile communications devices if Java were used. Why would consumers care what underlying device hardware were used if the software experience met their expectations?
The reverse scenario is, I fear (and I’m sure Sun fears this also), that the Java ME bits that reside on the billions of cell phones around the world sit mainly unused. Apple has taken this position with its closing of the iPhone and not allowing Java or Java apps to run on it. Could this be the sole reason that the iPhone is closed; to prevent Java apps from running on it and thus become a catalyst for the more portable Ajax revolution? I certainly don’t know for sure, but it’s an interesting strategy, trying to manipulate application developers to change their style to meet Apple’s future product direction.
Nonetheless, Sun is combating the problems related to fragmentation of Java ME on mobile devices with both JavaFX (in the near future) and the recent release of Mobile Services Architecture (MSA). MSA makes it easier for Java developers to get their mobile applications to run on more diverse hardware without the need to port it. You can read a recent Q&A posted on Sun’s site to learn more about the significance of this technology.
MSA targets a wide variety of phones, from the introductory “feature phones” to the more advanced (and more capable) smart-phones. There are also optional packages that support video and audio streaming, location tracking (for navigation applications on GPS-enabled cell phones), and game development. For a thorough look at what cell phones and mobile devices currently support which Java APIs, take a look at this device matrix.
So what’s more important to you? Sticking with Java, and the JavaFX strategy, where your Java applications will eventually be able to run on desktops and mobile devices equally, without targeting different APIs and JSRs and porting, or are you considering a move to Ajax, where applications run equally within a browser, say Safari, that is available on more and more of these platforms? Write back and let us know!
Happy coding.
EJB
Posted by Eric Bruno at 01:15 PM Permalink
|
|