| CARVIEW |
 |
|
 |
 |
||||||||||||||||||||||||||||||||||||||||||||
|
 John O'Conner's Blog
Major themes of JavaOne: REST, Ruby and NetBeansPosted by joconner on May 09, 2008 at 02:00 PM | Permalink | Comments (0)Hundreds of sessions, thousands of people...and what did I come away with? Lots of t-shirts, plush toys, and more t-shirts. Oh, and 3 main things related to my work: REST, Ruby, and NetBeans. REST -- Want to communicate with web services? You'd better learn something about REST APIs. I can't give a full tutorial here. I hardly know enough myself. But I can give you some info.
Some of the benefits of a RESTful architecture on the server side: scaleability, cacheable resources, reduced coupling. On the client side: resources are bookmarkable, you can easily test from a standard browser, you get broad programming language support for REST through standard HTTP, and you can get access to multiple formats for the data depending on your client capabilities and content negotiation. Ruby -- Lots of sessions talked about Ruby or JRuby. You couldn't escape Ruby. Ruby running on Java, Java from Ruby, Ruby from Java...it's a mixed up, crazy, beautiful combination. And you know the part I really liked. Apparently, once you create your application using Ruby (and Rails of course), you don't have to sound the alarms with your IT department by introducing another server to them. Supposedly, and I haven't tried this yet, you can deploy JRuby on Rails applications as WAR files on a standard Java application server. That's impressive. NetBeans 6.1 -- I know that you have many IDEs to choose from. And you may have already selected. But just do me a favor, do yourself a favor...take a new look at NetBeans. Version 6.1 has all-new support for JavaScript, excellent Ruby integration and editing, and access to databases and several application servers in a single download. I've been dabbling with Eclipse. I'm working with a team that's considering Eclipse as their new IDE after working with IntelliJ. I can't let them do it. I have to get back to them next week and stop them while they still have time. NetBeans, it's the only tool we're going to need to do our JavaScript and HTML front ends, business logic on the Java EE middle-tier, and even modify, edit, and maintain our MySQL database on the backside. Check out the latest NetBeans and see what you think. For more information about NetBeans 6.1, including my own more detailed review, check out NetBeans 6.1: Worth a Try. Creating OpenOffice ExtensionsPosted by joconner on May 09, 2008 at 10:33 AM | Permalink | Comments (0)One of the great things about many applications these days is their open API for end-user additions or extensions or plug-ins. OpenOffice allows you to add your own functionality to the application as well, and you can create those extensions with Java of course. And tools like NetBeans make this easier than you might suspect by providing wizards to help you get started. The OpenOffice API is called UNO, and after accessing the OpenOffice APIs from NetBeans or Eclipse or any other development environment, you'll package those plug-ins and extensions as .oxt files. You or your end users will install them by using the OpenOffice extension manager or by just clicking on the extension file. You might be the one to create the next great OpenOffice extension by integrating your application into one of the most popular open source office suites available. Learn about about OpenOffice and the UNO API by visiting the following resources:
Do we rely too much on XP?Posted by joconner on May 08, 2008 at 12:56 AM | Permalink | Comments (3)Earlier this year I decided to renew my commitment to learning something about Java ME. I went so far as to get a RIM Blackberry device when I had the opportunity to update my cell phone. Finding a Blackberry oriented session at JavaOne was just bonus material! I was excited to attend the session. I really wanted to learn how to develop apps for this excellent phone. So I attended the "Developing Java ME Applications for BlackBerry" session yesterday. They have an SDK plugin for Eclipse...and they said that some have even installed the SDK under NetBeans. Great. I can develop Java applications for the BlackBerry using my favorite IDE. Perfect. What? The Eclipse plugin only works on Windows XP...maybe Vista. Why's that? The BlackBerry session speaker says that the BlackBerry emulator was designed for XP. Won't run on the other platforms that Eclipse and NetBeans run on -- Solaris, Linux, Mac OS X. Sure, you can develop applications using Eclipse running on any OS, but you won't be able to use the emulator. Now why is that? Really, why? So, why use Eclipse as the development tool? Might as well be a Visual Studio plugin. There's another device with an SDK that works from an Eclipse extension. Those Sentilla devices, the ones on sale here at JavaOne. Excellent. Again, I can develop a Java application for a very small device with temperature sensors, an accelerometer, and even a radio. Very cool. I can write those Java applications using Eclipse...on Windows XP only because, well hell if I know, but that's what the booth worker says. By the way, have you noticed the preferred operating system for most of the presentations around JavaOne? It's Windows XP by far. That's my observation anyway. Your mileage may vary. Why is that? Why is XP the preferred OS? I have an idea, but you won't like it. Linux and Solaris are just too difficult to install and maintain for the typical consumer and even the typical developer. If you know how to tweak a kernel, or compile your own driver, maybe you'll get the mouse pad to work correctly. Maybe you'll get that bluetooth headset or bluetooth mouse to work if you find and edit the right config file. Before coming to JavaOne, I decided to replace XP on my laptop. I put Ubuntu on it. Seemed like a good idea at the time. The application package installer was easy to use. Installing Java SE 6 and then NetBeans was easy. Ubuntu found my wireless card too. No problem. No problem until yesterday. For some reason, Ubuntu refused to display my desktop taskbar and application menu at the top of the window after I logged in. Strange for sure. Since I'm new to Ubuntu, I didn't know how to debug that. I couldn't recover. After getting my Open Solaris disk at Community One, I figured I could install Solaris. I did. It's installed. Looks a lot like Ubuntu's desktop by default, very similar. Installing the JDK wasn't as easy. I had to install the JDK from a .sh script. There wasn't any clean, easy graphical installer. I felt a little pathetic at having grown so dependent on the easy installers we have on Windows. Although Open Solaris found my wireless card, I don't think the network tools are as easy to use as on Ubuntu. And the power manager doesn't seem to work. The os sucks the battery down way too fast. And I can't get my bluetooth mouse to work either. If I were a Linux or Unix guru, maybe I'd know the right place to find the correct settings or drivers. After I return home, I'll definitely replace XP on this laptop. Even if I could get used to the new tools, simple installers, and the idea of compiling my own applications on Linux or Solaris, I can't use the applications I really want right now. After all, I'd really like to use that Eclipse SDK for developing BlackBerry applications. I might also want to try my hand at writing an application for some other cool Java device. Too bad the tools only run on XP. Modularity in the Java PlatformPosted by joconner on May 07, 2008 at 01:37 PM | Permalink | Comments (3)JSR 277 is the technical spec for Java Modules, a way to promote the "module" concept in both your own applications and in the Java platform itself. In their JavaOne session this morning, the co-spec leads -- Alex Buckley and Stanley Ho -- clarified that the previous JSR 294 "superpackages" spec has been consumed by this new JSR. JSR 277 includes modularity concepts and features for both development and deployment. In short, the goals are these:
Today, Java development is dominated by packages. Although package names are hierarchical, package membership is not. You can't easily share types and members across packages unless the interfaces or class members are Modules in the JSR 277 definition would allow developers to associate classes and resources in different packages so that those classes can access each other more easily. Modules would logically gather those classes -- even if they exist in different packages -- into a common bag or module, providing the ability for those classes to work more directly with each other. In effect, you get yet another access modifier, something like What's the impact of modules on the Java language and VM?
How about developers? What's this module concept really mean for them? How do developers use it? Not much really changes in how you'll compile or run your applications:
Developers will be able to annotate classes (and modules) to describe modules versions, membership, dependencies, and other attributes. For example, you might use any of the following: @Version @MainClass @Attribute @ImportModules @ImportModule @ImportPolicyClass @ModuleInitializerClass @PlatformBinding @ExportResources Of course, you'll have to check out some of the technical docs and specs for more detailed descriptions of these and other annotations. But the info is out there. See the end of this blog for more information about resources you can use to learn more. JAM files and modules should help deliver you from so-called "JAR hell." JAR hell basically refers to the confusion that developers and applications struggle with when deciding which versions of jar files to use. Yes, jar files can have version numbers, and they usually do. But jar dependencies are difficult to specify, determine, and enforce. And without classloader tricks, you can't use two versions of a JAR file...maybe a new version in one part of your application and an older version in another. Think that's an unreasonable expectation? It's not. Consider the situation you're in with XML parsers, for example. Your app might need one version. But maybe that same app uses a third party library that uses an older version of that same XML parser. Resolving this can be frustrating. The new spec resolves some of this. Different classloaders handle each JAM. The modules system makes sure that:
The JAM specification is still in draft status. The co-spec leads say that the final spec will be available "soon," and I assume that means that implementations are not far behind. To learn more:
Reviewing NetBeans 6.1Posted by joconner on May 06, 2008 at 03:17 PM | Permalink | Comments (0)The NetBeans community approved and released NetBeans 6.1 last week. That's right before JavaOne 2008. That's convenient! And of course, some of the JavaOne demos have NB 6.1 running in the background. If you're at JavaOne, you can't escape it. NetBeans 6.1 is here. The latest NetBeans 6.1 has improved in these areas:
You can find out more about this latest release by checking out my online review: NetBeans 6.1: Worth a Try.
Free, open source Linux is for hippiesPosted by joconner on May 05, 2008 at 10:05 PM | Permalink | Comments (0)CommunityOne is the conference at Moscone Center just prior to the JavaOne conference, which starts in earnest on Tuesday May 6 2008. I'm here for JavaOne but couldn't resist dropping in on CommunityOne. CommunityOne's schedule includes several tracks today, including topics on web applications, scripting languages, Open Solaris, projects and strategy, and tools. NetBeans has its own track too. Frankly, I don't think the CommunityOne sessions were that interesting. The speakers obviously have other day jobs, and well, that's a good thing. However, the interesting parts of a conference like CommunityOne or JavaOne are not always in a formal session. The "community" is so diverse that I found myself drawn to the hallways and side tables just to eavesdrop on conversations. Some conversations were serious, others were fun, and one of my own was just...well, I'm still confused. It went something like this:/p> John (that's me): Hi, I'm John. I'm surprised how many people are here before JavaOne, for this conference before the big conference. Other attendee: Oh, hi. I'm Dag. John: Dad? Other attendee: No, Dag. D-a-g. John: That's an interesting name. I'm sure you have to spell it often. Dag: Yeah, all the time. But anyway, yes, there are a lot of people. The open source communities are huge. In fact, I'm here just for CommunityOne. John: Really, you came just for CommunityOne? Amazing. I sort of suspected that CommunityOne was just the thing to do if you were in town early. Dag: No way, the open source community is big, and supporters turn out in huge numbers. In fact, this year's open source day is 50% larger than last year. I think this is the turning point. Next year will be even bigger and better. John: So, what open source projects do you work on? Dag: Nothing. I'm a consumer. Our shop has used MySQL for years, and we've been using Linux too. John: Linux, huh. I'm trying Ubuntu on my laptop this week. I expected to see more Solaris CDs...you know, Sun is a big influence here. I'm surprised a cd wasn't in my tote bag. Dag: Although we've been using Linux, our management is pushing us away. Their impression of Linux is just too much for them. We're moving to Solaris x86 soon. John: What impression? Dag: Well, open source, Linux in general. It's just a hippy, fringe thing, you know. That's what they think anyway. John: Hmm...I guess I didn't know about that. Dag: Yeah, the managers also say, "Free, open source...you get what you pay for." So they're trying to push us away from Linux to Solaris. That's open now too, but the impression is different. They'll go for Solaris, but they're uncomfortable with Linux. John: Solaris is open-source, but the impression is different? Dag: Absolutely. Sun's a big company, with plenty of support options, big name, big brand. The managers trust that. John: They don't trust names like Red Hat? Dag: Eh, not so much. Hey, and you know what? You can get better, cheaper service support from Sun now than you can from Red Hat. Sun support for Solaris is cheaper than Red Hat support for Linux. John: I had no idea. So, you'll move to Solaris soon for the support? Dag: For the cheaper support, sure. And the name. The managers trust the name. Sun. Solaris. John: Brand recognition, yes, that's important. Still, I'm surprised that you can get Solaris support for less than Red Hat support. I haven't researched it myself, but I'll take your word on it. Dag: Yeah, support is very important. We can't just get something for free. The managers don't trust that. So, we have to pay for it somehow. So we'll get the support contracts; we'll write out those checks to Sun for support even if we don't pay for the software. John: So, they don't like open source because that also means free sometimes, as in no charge. But they'll tolerate it from someone like Sun because they get support from a known-brand company. Dag: Right. That's it. Hey, gotta go to that Project Darkstar session. I didn't tell the boss about that, but I want to check it out anyway. John: No problem. Enjoy yourself. Later! Hey, I didn't make this up. That was a real conversation. Strange but interesting, no? I still don't know quite what to make of it. And that's much of the appeal of CommunityOne and JavaOne, aside from the actual technical content. The opinions, the people, the conversations...always interesting even if you don't personally agree. Make sure you help create some of those conversations this week. Meet someone new. Don't hang out with your typical group. Get away from your everyday colleagues. Learn something new. Hear something different. That's the best way to get the most from JavaOne! P.S. I did eventually find a Solaris x86 cd. It was in the CommunityOne tote bag that I received when I picked up my free t-shirt. I want to try it but frankly I'm hesitant. I've never had much luck with it when installing to a laptop. If you've put it on a Dell Latitude D620 before, let me know...I might try it this year. But don't expect me to buy a support contract. Top 10 Desktop Sessions at JavaOne 2008Posted by joconner on April 23, 2008 at 03:58 PM | Permalink | Comments (12)
My list is below, numbered but in not in any particular preference order:
That's it! Join me for a few of these sessions this year. JavaOne is May 6-9 @ the Moscone Center, San Francisco, CA. And if you haven't registered yet, you'd better hurry. Encoding URIs and their componentsPosted by joconner on April 22, 2008 at 11:48 PM | Permalink | Comments (0)
The
The problem with this is that the escape mechanism is broken if you want to use UTF-8 as your document encoding. If you were dynamically composing URL strings with parameters, those parameters will definitely not be escaped correctly. Instead of
Fortunately, JavaScript has resolved the problem, but the solution means you'll have to use another function. The
What's this mean for you? Maybe nothing if you're hopelessly attached to ISO-8859-1. However, if you're trying to reach a global market with your product, chances are very good that you've decided to use UTF-8 for your character set encoding. That's an excellent choice, but you'll have to manage the conversion points. In a nutshell, that simply means that you'll need to use UTF-8 from front to back consistently.
Part of managing those conversion points is consistently providing well-formed URIs to your application server. If you use JavaScript to manipulate data or to create dynamic URIs in your application, make sure you toss aside that deprecated Character Conversion pointsPosted by joconner on April 13, 2008 at 09:07 AM | Permalink | Comments (2)
Here's an example: a simple web application that stores names and addresses in a database. Chances are, if you haven't done anything explicit to change this, the web page itself will have no charset encoding associated with it. And neither will your application server. And neither will your database. And without explicit settings, many applications use Latin-1 as the default character set. So, you'll be able to enter, store, retrieve, and display common Western European names, but you won't be able to handle Russian or Japanese or Chinese or, well, you get the idea. So let's imagine you decide to convert from Latin-1 to UTF-8 so that you open up your application to the rest of the world's languages and scripts. What does that mean? What must you do? How do you start? Here are some of the charset conversion points you'll need to resolve as you migrate through this problem:
To help you get started, I've discussed the first 4 conversion points in the article Character Conversions from Browser to Database. Go ahead, take a look. But come back here to let me know what you think. Old article, yes, for certain. However, I just ran head on into this very problem just this week. The same problems never go away, and this article had the content my team needed to resolve it in our environment. I'll talk about some of the JavaScript issues in an upcoming blog. Also posted to joconner.com. Another solution for non-UTF8 source files in NetBeans 6.1?Posted by joconner on April 05, 2008 at 09:55 PM | Permalink | Comments (4)Recently I mentioned a potential problem when saving source files in a non-Unicode charset encoding. The potential data loss is significant for large projects. After thinking about the problem a little more, I have a potential solution, a solution that allows you to save to a non-Unicode encoding but also prevents data loss. You are familiar with Here's how it would work. First, NetBeans 6.1 uses UTF-8 for a project's default source code and configuration file encoding, an excellent choice by the way. So, now imagine that your source code has the Euro currency symbol in it. That's Unicode code point
Now, let's imagine that you need to change your project encoding for some reason. So, maybe you choose ISO-8859-1, which doesn't contain the Euro symbol. You can still represent the Euro character, but you'll have to encode it with the \u. Wouldn't it be nice if NetBeans did this for you, creating So, what do you think? Maybe the NetBeans team can get this into the 6.1 product before final release? Have you seen NetBeans 6.1? Give it a try, and blog about it. Who knows, you might win $500! Also posted to joconner.com. Call for participation: Internationalization and Unicode Conference #32Posted by joconner on April 03, 2008 at 12:04 AM | Permalink | Comments (0)The Internationalization & Unicode Conference is the technical conference for software and web internationalization engineers. If you have a product that implements the Unicode standard or an idea that will help others work with this standard, share your knowledge. The "call for participation" is an invitation for Unicode gurus, clients, and vendors to submit papers for this upcoming conference. Learn more at the Unicode Conference web site. Also posted to my software internationalization blog at joconner.com NetBeans 6.1, UTF-8 encoded source files, and a tale of corruptionPosted by joconner on March 30, 2008 at 02:59 AM | Permalink | Comments (3)I'm always happy when a company or product adopts Unicode as its charset. I think it makes perfect sense to do so. There are lots of good reasons why standardizing on Unicode is the right thing:
I was pleased to see that NetBeans 6.0 and the 6.1 beta uses the UTF-8 encoding (a Unicode encoding) as its default for project configuration and source files. The following figure shows the default setting in the project's property sheet:
This makes it much easier to edit non-ASCII, non-English source and property files. You can type text in any supported Unicode script right into Java source code. A legitimate usage would be comments or even localizable text in javac -encoding UTF-8 YourSource.java Despite the potential benefits of this, NetBeans 6.1 still doesn't support this correctly in my humble opinion. Why not? Well, the biggest reason is simple: file corruption and permanent data loss. Ouch! Let's take a simple "Hello, world!" example in Japanese. This is simple for NetBeans because of the UTF-8 encoding. The NetBeans editor even displays it correctly as shown here:
Unfortunately, the joy of this discovery was short lived when I discovered how easy it is to corrupt this data. Feel like experimenting with the charset encoding? Surely someone will. I suspected what would happen, so I didn't do this with any substantial code base...but someone will. I sure hope they use version control software. Reopen that project property sheet, select another encoding, say
Some of you, the super careful, nit-picky ones will now argue with me, "But John, you haven't really lost anything yet. 8859-1 and CP 1252 don't have those characters, but the original byte values are still entact. You can get them back in this example." OK, I concede the point. But now I'll show you some serious data loss, no messing around this time. Instead of
Now that's just not good. Did NetBeans save the file correctly? Sure. However, NetBeans can do better than this. I would argue that if NetBeans knows that the target encoding does not support the source encoding, it should at least warn the user that the resulting file will contain garbage characters and that parts of the file will be lost--permanantly in many cases. So, just in case anyone over there in the NetBeans developer group can hear me...you have to fix this. Yes, I know it's a silly mistake for someone to do this, but NetBeans can help them avoid the problem. Just provide a warning dialog, "Saving this file in the target encoding will cause data loss because the target encoding does not support all characters in this file or project." Keep the encoding feature, just perfect it by helping some users avoid this costly mistake. The fact is that most software developers still don't understand character sets and encodings, and this is just an accident waiting to happen. On a personal note: I really love NetBeans. And I hope this blog qualifies me for the NetBeans 6.1 blogging contest! I could probably file this under the "suggestions on how to enhance NetBeans 6.1" category. Will blog, write, or program for JavaOne passPosted by joconner on March 26, 2008 at 12:01 AM | Permalink | Comments (0)
Although I was there last year -- writing, blogging, communicating to the community -- I don't have a pass to JavaOne 2008 yet. Unfortunately, I have no concrete plans. No corporate or community sponsor has agreed to help yet either. It's a sad, sad thing. Indeed, these are trying, desperate times. I want to go to JavaOne...and I'm willing to take drastic action. Sure, I could just put up the money myself. The $1595 price tag for a 4-day pass is expensive but not entirely out of my budget. Still, there's no fun in that, especially if I can do something more interesting than just sending in the registration cash. So, I'm going to do something a little different in order to participate this year. I'm hiring myself out! Yes, that's right. The first sponsor to offer a full 4-day Conference Pass and room will receive my professional consulting/writing/blogging/programming/go-fer services for the duration of the event! Here's what you'll get:
Yes, it's a bit unusual. But the JavaOne conference is unusual too. I think this is going to work out just great. You know how to reach me: john at joconner dot com. Beans Binding and my Flex friendPosted by joconner on March 23, 2008 at 10:53 AM | Permalink | Comments (8)
I recently wrote a brief introduction to Beans Binding called Synchronizing Properties with Beans Binding. I was enthusiastic about Beans Binding, and then a coworker threw a wet towel on me. The conversation went something like this: John: I just finished an article on java.net. This API might be useful in this project. Coworker: Yeah, what's that? John: Beans Binding. It's an API that will help us bind beans together, synchronizing properties. Coworker: What do you mean? John: You know...say you want to update a table with new data anytime a result set changes, or maybe you want a price field to display the current total of all purchased items in a shopping cart. You can use beans binding to synchronize the properties without having to write all the plumbing and event handling yourself. Coworker: Hmm. Java hasn't always had that? John: Well, yes. Java has always allowed you to synchronize properties, but we've never had an API to make it this easy. Coworker: Really? We've had this in Flash and Flex forever. John: You've had binding? Coworker: Binding, or Beans Binding...whatever you call it. We can bind a variable or property to another variable or property so the updates trickle throughout the application. It's a great feature, a must-have, and I couldn't do without it. I use John: Yes, it's great. I agree. So take a look at that article. Beans Binding, it's pretty cool. Coworker: You're just getting binding in the Java language? Hmm... really? I just assumed Java would have had that all along. John: Um, it's not exactly part of the language. It's a new API. Making changes to the language is difficult and usually takes a long time... Coworker: Oh, I misunderstood. It's not part of the language? Just a separate API? Got it. Hmm...ok. Well, uh, gotta run. John: Hey, wait. But Java FX Script has a Coworker: Right. Java FX Script. It's about time Java got got a bind operator or keyword, something. John: No, not Java. Java FX Script. That's the new language for rich client app development. Java FX Script has the Coworker: OK, right...well...hey...I have to get back to work on this Flex app. But I agree, binding is great, couldn't do without it, use it all the time. Videos and the cubicle effect on content consumptionPosted by joconner on March 20, 2008 at 02:54 PM | Permalink | Comments (6)They do great work over there on the java.sun.com editorial team, and they've been improving the site with lots of videos lately. The last three featured content pieces have been videos. That's excellent work, but it's inaccessible for a couple reasons. First, I like to hit java.sun.com first thing in the day from my workplace. That's been a cubicle environment recently. I can quietly read a text article, even print it and read it later during a lunch break. Unfortunately, I can't do the same with the videos. They're fun, sure, but unwatchable because video and audio are distracting to others in the office. Bandwidth issues aside...people just don't like to hear this from another cube. I understand that, so I don't intrude on their peace and quiet. Unfortunately, the video is inaccessible to me. And when I get home, well, there's a better than even chance that I won't watch a tech video then either. Second, the videos are inaccessible to those with hearing or sight impairments. Seems obvious, right? Can't hear...the audio isn't usable. Can't see...can't watch the video either. I suppose you could listen to the video -- but not in my cube. So, the videos are inaccessible to others too. Granted, those who can't benefit from the videos are a small minority. Still, wouldn't it be nice to include them as far as possible? I think a solution is possible. Video is a great idea for java.sun.com, and clearly the medium is popular. Just witness the popularity of YouTube, etc. I think the videos could be improved though with something very simple. Transcripts. Providing a transcript with the video would allow cubicle dwellers access to the content. The same transcript makes the content accessible to hearing and site impaired developers too. Can't hear -- you can read the transcript content. Can't see? Text readers exist for that case. Either way, the videos become more accessible to a larger group of people. Is this a complaint? No way. I enjoy practically all of the content provided by java.sun.com. This is just a friendly suggestion, hoping that it will bring the content to an even wider audience. It has been a long, long time since I last worked in a cubical environment. I find the experience undesirable but tolerable. It makes me curious though...just how many of us work in a cube environment? Might be a great polling opportunity for the java.net editors... Should we expect more db acquisitions?Posted by joconner on February 24, 2008 at 08:10 PM | Permalink | Comments (3)Last month Sun announced it had acquired MySQL, which may very well be the most influential and widespread open source database in the world. Aside from a few announcements, there wasn't nearly as much comment on this as I expected. Here are the databases that I see being supported at Sun:
HSQLDB? You would agree that Sun is the largest supporter of Open Office, right? I mean even though OO is open source, that doesn't mean it doesn't have huge corporate sponsorship. And that huge corporate sponsor is Sun, which donates time, material, money, employees, and advertisiing to Open Office. Open Office has adopted HSQLDB as its internal database. Surely HSQLDB's project gets support from Sun too. After all, it is an integral and important part of the Open Office suite.And its a 100% Java implementation. Maybe this isn't an expensive investment compared to MySQL...but why bother with HSQLDB, especially when you have this next db? Apache Derby. Sun's branding calls this Java DB, but underneath, it's still Apache Derby. Derby is the 100% Java database that supposedly can scale from embedded applications to larger, departmental, transactional apps too. Impressive for sure, but certainly duplicated by the HSQLDB product's abilities, no? Regardless of the overlap in abilities, these are two different products with different supporters and communities. Still, that's another db, and more money, time, and resources from Sun. Then we have the heavier hitter, MySQL. And this is by far the biggest ticket item. What was the price? $1 billion? I put this db in a different league from HSQLDB and Derby. 100% Java? Not at all. However, it does have more enterprise credentials than either of the other databases. It's probably not fair to even put the others in the same arena as MySQL. As I dig around, I see that Oracle purchased Innobase, the company that provides InnoDB within MySQL, a couple years ago. So, Oracle owns InnoDB, and Sun owns MySQL. Interesting, but what's that mean about InnoDB within MySQL now? I see Sun developing more and more interest in database technologies, from small systems like HSQLDB and Java DB to the larger MySQL. It's a pattern, and I wonder what it means. Can we expect Sun to actively support and even purchase more db technologies? What might those be? With limited time resources, I can't work on all the things I'd like to. I can't read all the books I would like to. I can't give to all the charities that deserve my attention -- or money. I think companies have similar constraints on their resources, money, employees, etc. As far as I can tell, Sun has now made committments to at least three different database systems. Which one will prevail at Sun, and which will get the resources to maintain itself? Java applets not viable for this application?Posted by joconner on February 22, 2008 at 10:10 AM | Permalink | Comments (28)I've been working with a company that creates a chat system that helps companies sell more of their products online. The backend is all Java, complete with Spring, servlets...all good Java stuff. The frontend is...well, it's Flash. Preferring Java everywhere when possible, I asked about the Flash choice on the customer-facing app -- the actual chat client. The conversation went something like this: John:Wow, this product uses Java everywhere except on the front, where the customer actually interacts with it. Why choose Flash there? Dev mgr:Well, Flash was just easy. It was simple to use for such a simple UI too. John: I see, but it's pretty easy to do that chat UI in Java too. Swing's layout managers are easy now, particularly if you use an IDE like NetBeans to layout the UI. Dev mgr: That may be true, but the choice is based on more than just ease of creating the UI. John: Yeah? So what's that? Dev mgr: Flash is on every client browser. We don't have to install the runtime. John: Java should be there too, right? Most PC manufacturers include it. Dev mgr: Maybe, but we know Flash will be there. Flash is all over the web, and chances are that a customer has the runtime already. If they don't, the download and install is fast and easy. John: OK, but Java will also install easily. Dev mgr: But Java takes so long to install. It's too big. John: I don't know if that's so true anymore. There's been a lot of work to make the runtime smaller and more compartmental. So you only download what you need. Dev mgr: What we need is something very, very simple. A very simple UI with simple functionality to relay chat text. Flash does the job well. The conversation continued...but I didn't get too far. Maybe Flash does do applets better than Java? Working with Sun for so long, I just naturally imagined that Java was everywhere and that everyone else loved it too. I've always been able to make things work...but apparently not everyone else has. The download size never bothered me...but it does bother some others. Additionally, I find that perception is as important as reality. So what if Java is now faster, leaner, and great working within browsers? Somehow it doesn't matter. The old perception is still out there -- that it's slow, huge, and difficult to work with in a browser. It's amazing to find out that some just don't see Java as their solution in that space anymore. I called a few friends who put together consumer-oriented websites. They use Flash too. What about Java? Sure...all on the back end business logic. But what about applications that the customer will use? If they're embedded in the browser, they're using Flash. Wow. So, how would you approach this? What does the Java community need to do to fight back old perceptions? Why is Flash so much more popular in browser based applications? And how can we get Java there instead?  |
|
May 2008
Search this blog:CategoriesAccessibilityBusiness Community Community: Global Education and Learning Community Community: Java Communications Community: Java Games Community: Java Specification Requests Community: Java Tools Community: Java Web Services and XML Community: JavaDesktop Community: JDK Community: Mac Java Community Community: NetBeans Databases Deployment J2EE J2ME J2SE JavaOne JXTA Open Source Programming Swing Tools Archives
May 2008 Recent EntriesMajor themes of JavaOne: REST, Ruby and NetBeans Creating OpenOffice Extensions ArticlesSynchronizing Properties with Beans Binding (JSR 295) All articles by John O'Conner » | ||||||||||||||||||||||||||||||||||||||||||
John O'Conner is a software architect, consultant, author, and speaker.
After many years developing the internationalization features of the
Java platform at Sun Microsystems, he is now actually trying to use
those features in real world projects.
I've been doing a top 10 list for a couple years for JavaOne technology tracks. No need to stop now. So let's jump right to it. If you're interested in what I think are the top 10, must-see Java Desktop sessions at JavaOne 2008, the Desktop sessions that will influence you the most in the coming year, check them out and make sure you use the online 
As you pass data from the browser to the application server to the database, opportunities for data loss lurk. I highlighted some of those 
You'd think this sort of problem would be resolved by now, but it's not. It's still almost impossible to quickly and easily migrate an application from the too common default Latin-1 to UTF-8 character set encoding. The problem isn't that UTF-8 can't handle the conversion. No, that's definitely not it. UTF-8 can represent any Latin-1 character and much, much more. The problem is that the Latin-1 charset is so deeply ingrained as the default in every software interface that you just have so many faulty conversion points. A conversion point is a handoff point between one software component and another, a place where character encodings matter and where faulty conversions are way too common.
 java.net RSS Feeds
|
