Thursday April 27, 2006
Visual Basic, C# and Java
Filed under: net2java
You know how when there are two leading and competing products A and B, and you see the companies that make them playing the switch-trick ? The company that makes product
A guns for
the people using product B and make it super easy for them to
switch to product A ?When I first came to the US (yes, I'm not from here), before landline telephone companies had major migraines like wireless and VOIP to deal with, the leading two providers, MCI WorldCom and AT&T used to spend a lot of time and effort poaching each other's customers. Like me. Aside from the free service for however long they would give you (from which some of my cannier friends would profit on a regular basis), one phone company would take care of the sanity eroding task of canceling your account with the other. No left-ear-numbing wait for customer service while destroying a piece of music for all time that you used to enjoy, like Handel's 'The Arrival of the Queen of Sheba' on infinite repeat, in anticipation of a half-hour interrogation as to why you wanted to change your account. Usually by someone who was audibly, emotionally and ceremonially not the Queen of Sheba.
Switch to Java ?
So what with most developers in the world programming either in Java or a .NET language like VisualBasic or C#, it makes me wonder: where are the clever tools or frameworks or experts to make easy transitions from one side to the other ? Sure there are tools here and there. Microsoft made it easy to transition off J++ into one of the other two, but that's of course not the same. (yet happily so for that village of developers, because there was a whole city that did not fare so well.)
Now you're not telling me that there aren't big companies with developers some of whom develop in .NET and some of whom develop in Java. J'accuse ! So don't they ever do lunch, and don't the Visual Basic or C# developers ever want to dip their toes into our wonderful world of Java and see what the hoopla is all about ?
Shameful Past ?
In fact, Charles has been trying to delve into who these people are and what's in their secret pasts. If that's you, go tell all your shameful secrets in his poll.
If those people do want to see how we Java programmers enjoy ourselves, they will find some tools to help them. But, and the valiant folks providing them I hope will forgive me for saying this, they are few, far between, not always terribly up to date, and unsurprisingly, given the titans of this industry don't support them well, limited in their ambitions.
Suspicions ?
I have several theories as to why this is. One of course is that there are many other factors that keep developers (and sometimes more importantly, the budget holders in their workplace) loyal to what they already know. So the pressure to migrate people backwards and forwards has to come from the top down; not always an effective strategy with independent minded developers with choices.
But really I think a lot of the problem is that automating the migration of applications from one platform to another is a very large and difficult task to do well in a general way. First of all the .NET and Java platforms are very, very broad. There are lots and lots of API calls that any single application could potentially make. So any kind of automation has to be ready for any one of them. Second of all, many applications use bespoke components that are not necessarily availble to this valiant group of people out there trying to support such migrations. So as specialized as these components are to one particular company or setting, equally specialized are the processes that would enable them to be migrated. Again, hard to get right for the general case.
Something to ponder on.
Until the Arrival of the Queen of Sheba ;-)
Wednesday April 19, 2006
Speaking in many tongues
Filed under: javase6
I've talked about support
for other languages in the Java Platform before, and indications
are (here's an informal
example) that many of us developers who use Java also use another language.So I hope you read that Mike and Sundar have set up a java.net project to gather the language interpreters for the Java platform into one place. So far the current count, for the triskaidekaphobics, is a baker's dozen.
If your favorite is not amongst them, here's a few more.
It's one of the reasons to be excited about Mustang.
Friday April 14, 2006
Java SE Language: Eadem Mutata Resurgo*
Filed under: javase7
Part of the reason working in the Java SE group is so interesting is the diversity of the developers using the technology. As developers, we're writing a wide variety of applications in a wide variety of different domains. Java SE may only be a part of the software stack we're depending upon. Often we're working with Java SE within a Java servlet, or EJB container. Java language changes are of special interest to us in the Java SE group, because wherever we are as a developer in the software stack, additional features we add to the language make a different to us all.
Curling the Chip
There was a story in The Economist a few years ago about innovation. I hate to paraphrase such a good article, but that grain of golden sand appears to have crept to the deep. One of the points was to contrast product innovation for new products and for established products. A wholly new product has no customer base. No commitments or expectations. The successful innovations tend to be big new ideas, or a disruptive application of an old idea in a totally new setting. Like the Sony Walkman was. Innovation for established products is arguably more difficult: you have customers who already like your product who you want to keep. There are teams of people building, delivering and selling your product that would be difficult or expensive to change. So your ability to innovate is much more constrained. But the article gave the example of a company making potato chips that were popular, but not popular enough. Rather than invent some wholly new potato based snack, they put a curl at the end of each chip. There was minimal disruption to their production processes. Customers didn't notice anything new till they opened the bag. There are two happy endings depending on your perspective. One happy ending is that people loved them because they could shovel more dip onto them. The other is that people loved serving them because there was less spillage of dip after the party was over. Either way, sales jumped dramatically.
Java SE Language Changes
So to some extent, with a successful technology like Java SE, good things to look for on the horizon are the metaphorical curls in the chip. Non-disruptive innovations that have widespread consequences. Given that many Java developers are Java EE developers, its no wonder that the use of annotations has been such a big hit. As Graham's been explaining, that curl in the chip has scooped up a big wobbling dollop of complexity out of the EE deployment descriptors and programming model.
Here's a selection some of the possibilities I've been thinking about. Doubtless you recognize some of them.
Property support
This would be a language syntax to support short handing the variable foo, getFoo(), setFoo() pattern. Definitely a pattern that is routine and dull to keep replicating by hand.
Method References
Writing and wiring event listeners is a frankly a bore. For example, implementing and wiring a button to call the updateLastName() method on your AddressBook object when clicked gets old if you have to do that kind of thing a lot.Wouldn't you prefer something like button.addDelegate(delegate updateLastName) and get it over with ?
Block Closures
A block closure is a group of statements defined within the context of...another group of statements. So block closures are statements within a statement ! (A Dream within a Dream. My entry found its theme.). Inner classes are the poor man's version of this: they are hobbled because the only thing they can do with local variables is read those that are final (why is that ?). Plus some people think they are plain ugly. Block closures could be an enormously powerful way make code very compact. But is there a syntax that pairs brevity with readability ?
Partial Classes
Unlike the esoteric predecessor, this is just the ability to deposit the source code for a class in various different places, like separate files. The most familiar usages are by tools that auto-generate parts of a class for you, perhaps a GUI builder tool, leaving you to fill the rest out in fear of the warning comments bespattered around the source file. With a partial classes mechanism, the machine generated part could live safely in one file, and the bit you work on in another. Simple and tidy.
Finally
So I wonder which of these, or the many other potential language changes could be the next curl in the chip for Java SE 7 'Dolphin' ? And in particular, which could be used by the Java EE platform with powerful consequences ? And keep to our principles ?
* So what's with the title this time ? Of course, Eadem Mutata Resurgo means "I shall arise the same, though changed" which is relevant to the topic. Plus my brother read my blog and gave me some typically fraternal feedback ('excruciating' was one word he used :-) ). So the title is also his college motto. You've got to throw the non-engineers a bone now and again.
Posted by dannycoward ( Apr 14 2006, 12:21:21 PM PDT ) Permalink Comments [5]
Thursday April 06, 2006
Modularity on the Java SE horizon
Filed under: javase7
I have confined myself thus far to talking about things in Java SE that are within hands reach. I thought it was time, especially with JavaOne coming up, to take a peek further ahead, see what's on the horizon for Java SE beyond Mustang.
For a technology that has found the range of venues for deployment that Java technology has, it still amazes me that under these competing demands, Java the language and Java the platforms have remained so consistent. But in places, the signs of age and stress are showing. In order that Java can continue to be many things to many people, its natural to look to ways to flex under the stress, rather than snap. And with an industry depending on the technology, in an evolutionary, not revolutionary way: Modularity.
So where are the stress points, and what can we make out on the horizon ?
1. Packaging and Deployment Modularity
The JAR format was first introduced in JDK 1.1 as a way to package application classes needed by an applet. Now its used as a general purpose format for deployment, packaging, caching, execution and distribution. On view on the horizon is the Java Module System JSR. Its vision is that instead of a tangle of JAR files (some needing a diet) of unknown versions secreted in various places, strung together in hope by a complicated classpath checked only at runtime, organization will be brought to application packaging and deployment in the form of a neat repository of medium sized code archives quietly expressing detailed and fully resolved dependencies on one another. Easy to manipulate, easy to distribute.
Easier to bring some much needed help 10% of PC users ?.
2. Language Modularity
Of course, as I mentioned last time, this is about supporting your other favorite language rather than turning Java into something it isn't. OK favorite within reason: dynamic ones. Maybe if your favorite language is c we'll need to talk. As I'd mentioned, quite close to hand is the Scripting for the Java Platform JSR makes a start by providing a basic facility for layering an interpreter on top of the JVM, enabling applications to mix Java and other languages.
But the compilers for dynamic languages are difficult to write well. Why is that ? Well, its a bit like doing your taxes without either an accountant or TurboTax.
Its about form filling: The main problem for writing a dynamic language compiler that creates Java bytecode that behaves optimally at runtime is that the Java VM depends on finding the method parameter and return types of a method call in the class file of the object making the call. The whole point of dynamic languages is that you don't know the types at the time you make the class file i.e. compilation. So todays dynamic language compilers usually employ complicated schemes of generating interfaces on the fly to represent unknown types, just to provide the form filling required to make a class file. It makes them slow, and when the developer changes code and recompiles, those magical interfaces need to checked and/or generated.
So on the horizon, the newly approved Supporting Dynamically Typed Languages on the JavaTM Platform JSR aims to remove that beaurocratic barrier to to dynamic language support by adding a new slot in the bytecode format. A slot not used by the Java language ! (not yet...)
Relief for the dynamic language folks ?
3. Application Code Modularity
Java already has various tools for decomposing and organising program code. At the small scale, classes to organise related functions and operations. OK so far. At the team, larger program scale, packages. But packages are a little stressed out too.
Let's say you want to publish a data model you wrote representing players in a tennis league. So you make the relevant classes and methods public. No harm in anyone picking up the code to do that. Like the developers of your tennis club's website. As the code evolves, you find yourself adding some interesting data exporting methods to help you interface to a database. Great, better make all that public for your database developers. Now your web developers and your database developers have exactly the same view to your code. Oh dear. The web developers are confused by the database related methods and some are using them by mistake. Better move that to a different package. But didn't you want it in the same package because its all related ? And, sigh, now you have to turn some of the package-internal classes public so the classes in the new package can still use them. Now the crazy web developers are using those classes, and they are asking what the new package is for. Double sigh !
Replace tennis club with insurance brokerage and a few thousand lines of code with a few hundred thousand and you probably already got the point.
Gilad amongst others has been toying with a few ideas here which I hope will come into range soon. Think 'friendly' packages, think 'organized' packages.
So, some interesting things on the horizon. Come to JavaOne, or stay tuned here - if I squint I can see a few more things out there...
