Thursday March 30, 2006
Don't let the language choose you
Filed under: javase6
I have a mixture of feelings reading all the recent drama when James mentioned scripting languages. On one hand I love to see people who are passionate about their profession. On the other hand, some of the debate has been rather shrill.
The world has moved on 10 years since the Java language was shiny and new, when its c-like syntax was so reassuring to the generation of developers who have now learned it. I did feel like the exception at the time, because my first language was Smalltalk (aside from some tinkering in c trying to find rational points on elliptic curves which we won't go into). For me, now as it did then, the language debate mostly reduces to ongoing choices we each make about our development style and how it applies to what we're trying to do. And choices we should feel free to make differently in the future.
Am I organized or organic ?
One axis along which languages are compared is whether they are statically typed like Java or C#, where you have to declare as you use a variable what its type is, or dynamically typed, like Python or Smalltalk, where you can defer that decision till later. If you answer yes to one or more of the following...
- You spell check all your emails
- Your books at home are arranged in alphabetical order. repeat with CDs. Spices ??
- You look at a movie trailer and think, "I have that font."
- You have moments of truth
to do with parsley and the teeth of people you don't know well
Statically typed languages require you to plan ahead, declare your design intention, and take an organized approach, or if you do not fold your metaphorical napkin after eating, the compiler will catch you. With dynamically typed languages you can be much more experimental, forging ahead altering API protocols as you go, like a Jackson Pollack, living closer to the edge and in the world of runtime exceptions.
Do I already have a design in mind ?
Which is why many people love dynamically typed languages for prototyping applications, where an organic approach, and ad hoc design, can lead to quicker results. And that's not the only situation. Web programmers live on this edge all the time where both the application lifecycle is quick and the application lifetime is short. They need to rip and replace quickly, using languages like PHP.
The 'design as you go' style of programming is much a more weighty task if you're using a statically typed language (which is why I *heart* the refactoring tool in NetBeans). But when it comes to working in larger teams, where you're using APIs being evolved by other team members, that statically typed languages come into their own, despite some people's personal taste. Larger scale programming jobs require team members to define what interfaces they are using, and publishing, before they use them, usually meaning the they save development time and maintenance effort. The forethought required by static languages lends itself to the planning and communication required by larger teams of developers working on a larger scale system.
Is the language the only thing you choose ?
I think this is one of the reasons I find it hard to get really worked up in this debate, because the answer to this question is often no. If you choose a language, do you have access to enough supporting libraries or platform APIs ? Can you choose the tools you wanted ? Did your favorite vendor or community cabal support this ? Can you explain it to your IT Director without blushing ?
In .NET your passion for Visual Basic could lead to untoward consequences. Like limiting your potential to choose platform libraries, OS and hardware. Or even leading to a dead end !
Freedom to choose the language you like
For the Java SE platform, we are firmly on course to keep you flying the flag for some of your favorite languages, particularly dynamic ones. In Java SE 6 'Mustang', I'd already mentioned that you can run JavaScript on the JDK out of the box, and made supporting other scripting languages pluggable.
This is a great start, but there's more coming: what with Java being statically typed and all, writing interpreters for dynamic languages is a tricky business, so Gilad started a new JSR to add a new bytecode, and maybe hotswapping, especially for this purpose, which we hope will result in more and better language engines for the Java platform.
(I'll have a related surprise of my own soon for you - stay tuned !)
So you see for Java SE, we're making it so you choose the language, not the language choose you.
Thursday March 23, 2006
The 10 Things You Need to Know About Java SE 6 'Mustang'
Filed under: javase6
Need a digest, summary, compressed form, precis of what's up with Java SE 6 'Mustang', currently in beta ?
Here it is, the top 10 things you need to know.
1. Web Services
All developers get first class support for writing XML web service client applications. No messing with the plumbing, you can expose your APIs as .NET interoperable web services with a simple annotation. Not your style ? Want to handle the XML directly ? Knock yourself out: Mustang adds new parsing and XML to Java object mapping APIs, previously only available in Java EE implementations or the Java Web Services Pack.
2. Scripting
You can now mix in JavaScript with your Java Source code, useful for prototyping, or when you have teams with a variety of skill sets. More advanced developers can plug in their own scripting engines, and mix their favorite scripting language in with Java as they see fit.
Perhaps You ThougHt yOu couldN't program with a scripting language and Java togetheR. Which will yoU Be trYing ?
3. Database
All developers get the updated JDBC 4.0, which is a new upgrade of a well-used API, focusing mainly on making it easier to use, although there are many feature additions like special support for XML as an SQL datatype, and better integration of BLOBs and CLOBs into the APIs. My favorite ease of use things include removal of some JDBC boilerplate, and some of the new annotations which make SQL strings embed better into your JDBC application. Like decorating your getAllUsers() method with an @Query(sql="select * from user") annotation, and that being all you need.
4. More Desktop APIs
Much has been said about this spoonful of sugar (to go with the desktop team's cake), so I will only skim a little. GUI developers get a large number of new tricks to play like the ever popular yet newly incorporated SwingWorker utility to help you with threading in GUI apps, JTable sorting and filtering and a new facility for quick splash screens to quieten impatient users.
5. Monitoring and Management
Really the big deal here is that you don't need do anything special to the startup to be able to attach on demand with any of the monitoring and management tools in Java SE. Mustang adds yet more diagnostic information, and we cobundled the infamous memory heap analysis tool jhat for forensic explorations of those core dumps.
6. Compiler Access
Really aimed at people who create tools for Java development, and for frameworks like JSP or PHP engines that need to generate a bunch of classes on demand, the compiler API opens up programmatic access to javac for in-process compilation of dynamically generate Java code. Not directly intended for the everyday developer, but for those of you deafened by your screaming inner geek, roll up your sleeves and give it a try. And the rest of us will happily benefit from the tools and the improved Java frameworks that use this.
7. Pluggable Annotations
Its becoming a running joke in Java circles, at least some that contain me, that for every wished for feature missing in Java, there's a budding annotation that will solve the problem. Joke no more, because Java tool and framework vendors can put a different smile on your face, defining their own annotations and have core support for plugging in and executing the processors that do the heaving lifting that can make custom annotations so cool.
8. Desktop Deployment
Those of you deploying applications to the desktop will soon discover that its a tale of a large number of smaller changes that add up to a big difference to existing applications. Like better platform look & feels in Swing, LCD text rendering, and snappier GUI performance overall. Java apps can integrate better with the native platform with things like new access to the System Tray and Start menu of the platform. At long last, Mustang unifies the Java Plugin and Java WebStart engines which just makes sense. Java WebStart application installation got a much needed makeover.
9. Security
You can have all the security features you like in the platform (and Mustang adds a few more, like the XML-DSIG APIs for creating and manipulating digital signatures), but if you don't have well supported security administrators, your security may be at risk. So Mustang has simplified the job of its security administrators by providing various new ways to access platform native security services such as native PKI and cryptographic services on Windows for secure authentication and communication, GSS/Kerberos services for authentication, and access to LDAP servers for authenticating users.
10. The Ilities: Quality, Compatibility, Stability
You probably knew that Sun has done regular feature releases of the Java SE platform over the last 10 years, so we certainly feel like we've built up some expertise in this area (the ever growing 80,000 test cases and several million lines of code testing conformance being just one aspect of our testing activity), but different from the last release, you probably noticed that people have been downloading snapshots of Mustang for the last fifteen (not just six) months. And what's more they've been filing bugs. And what's even more we've (and some of you!) been fixing them as we go. We're even challenging people to find more. So unlike previous releases, before we even got to beta, we'd fixed a number of quality and regression issues. Doesn't that add up to a better product ? Oh, and by the way, performance is looking better than Java SE 5 'Tiger'. Already..
So now you know all you need to know. Go on, try it !
Friday March 17, 2006
Java SE Ecology
Filed under: javase
I've been trying to find a good way of summarising everything that's new in Java SE 6. I know folks have been blogging like mad about it, but sometimes its can be useful to take a step back from the detail see it all at once. I'll write something that sums up why I think Java SE 6 is an important release next week.
In the meantime, I got to thinking, who is Java SE 6 for in any case ?
That's easy: its for end users who use the applications that need Java. Hmm, or is it for the developers that develop those applications for the end users ? But then, parts of it, like all the docs we provide in Java SE releases, are for the educators who help developers grow their skills in Java programming. Or other times, its for people who develop tools and frameworks that help the developers.....
Clearly, we have many masters. So then to get things straight, I drew a picture.
The
longer you look at the picture, the more you will see that the blobs
are just groups of people doing things to do with Java, and the lines
represent a relationship between them. You, gentle reader, might wonder where you are on the diagram, or where your blogospherical virtual self is. You're probably nestling in one or more than one of the blobs. Or you might wonder where a company like Google is on the diagram. All over ! They are certainly avid Java developers, they help produce the Java SE platform itself, for example, through the JCP. I'll bet Google employees use many Java applications themselves, so they're in that blob too... You get the idea. Repeat for your favorite company. (aside, how many companies are in all the blobs ?)
I suppose the lines with the arrows are a little curious: they're showing, in the direction of the arrow, the flow of something of value. Like for example, following the line between the Producing Java SE and the Developers: the value of many of the new things in Java SE 6 for Java developers: like Web Service APIs, JavaScript support et cetera. Or following the line between the Java developers and the people who use the applications, an example close to my home is the value in terms of time saved I get from being able to pay my bills online. All because of the Java applications running my online banking developed by a certain well-known bank.
And so on with every other line in the diagram.
Flowing up the lines, in the opposite direction of the arrows, is a litany of both praise and complaint which, if the people in the boxes upstream are half awake, they will do well to pay careful attention to, and use to maintain or increase the flow of value back downstream. Otherwise, they will find those lines shrivelling up, or rapidly connecting to some other mysterious blobs lurking beyond the edge of the page....
Isn't it interesting to see how many paths those of us involved in producing the Java SE platform have to, say, the End-Users ? Some more direct that others.
Of course, money flows mysteriously around this little ecosystem, but really to get that straight, we need a bigger picture :-)
Posted by dannycoward ( Mar 17 2006, 05:36:10 PM PST ) Permalink
Friday March 10, 2006
Crash Course: Java SE Monitoring, Management and Troubleshooting
Filed under: javase6
(Pardon the pun...)
At a meeting of Java developers earlier this week, I was struck by the convergence of three things. Just about everyone appeared thoroughly expert in the Java Platform, most were developing on Java SE 5, engaged in commercial product development of some sophisticated nature. Yet surprisingly few were familiar with our toolbox of management, monitoring and troubleshooting tools in Java SE 5 (and 6!).
You see, lurking under the surface of your application as it buzzes along may be a number of issues that can difficult to diagnose by reading your code alone. Causing seemingly non-deterministic behaviors (yes, those elusive intermittent bugs that cannot be reliably repeated) and performance degredations in your application, these issues are usually caused when you forget to dereference objects which squat unhelpfully in memory, or two or more of your threads clash and sit in perpetual stalemate, or other such esoterica. Left untended for long periods of time, they can even bring down an otherwise stable VM.
So cast aside the crystal balls, divining rods, tarot cards, or calls to Dionne Warwick that you may use currently to guess at memory leaks, thread deadlocks, dirty references, infinite loops, garbage collector histories: I'm going to give you all a crash course in the management and troubleshooting tools lurking in the /bin directory of your JDK.
Picture = 1k words
First thing, is to get into the habit of starting JConsole as you test your application - its (literally) your window into what's going on and is as good looking as all get out:-
You may just get into watching your application all day long, or JConsole may in fact solve your problem, it will certainly be apparent with use that there is a problem, especially if a memory leak or thread management issue. You may figure it out from here, or you may want to delve a little deeper into the command line tools...come with me...
Where's my VM ?
The jps tool. Roll call of all the names and numbers of all the Java processes on your machine. You'll need this for the other command line tools, as they need to know which Java process you want to look at.
Anyone seen my memory ?
Ahh, jmap and jhat, the forensic experts of memory diagnosis. jmap's role in life is to take a detailed 'photograph' of what's going on in memory at any one point in time, and jhat is the forensic expert that will help you interpret it. If you have a wonky application that's causing VM crashes, you can even set a VM option to have jmap take a farewell picture of memory state as the VM comes down. I must say that in looking though the neat website that jhat creates based on a jmap memory 'photograph', my inner geek was crying for joy to see the memory usage and instance counts of my classes that I could have it slice and dice every which way.
Threads in a tangle ?
Our friend for diagnosing thread problems is jstack who takes a 'photograph', on demand, of all the threads and what they are up to in their own stack frames. This includes the information from the traditional CTRL-Break or CTRL -\. jconsole arranges this rather output well, and check out the new button for detecting deadlocks !
Time to lift up the hood
Last stop on our tour is jstat. Really for the hardcore troubleshooters amongst you that want to see into the gizzards of the HotSpot dynamic compiler and garbage collectors. Very handy in a large number of situations where performance is suffering because memory is not being reclaimed like you think ought to be.
OK, that really was a whirlwind tour, but I hope you get a flavor if you are new to this area. All of the above is current in Java SE 6, and most true for Java SE 5. For SE 6 we made it using the tools 'hands-free' (i.e. no special VM options), we added more information within the tool outputs, and we co bundled jhat.
For those interested in more, stay in touch with the Java SE experts on this - Alan, Kelly, Mandy and Sundar.
And if THAT'S not enough, and you want to write your own monitoring and management tools, either for Java SE, or your application that runs on it, you really should talk to Eamonn.
Posted by dannycoward ( Mar 10 2006, 05:59:25 PM PST ) Permalink Comments [1]
Monday March 06, 2006
Principles for Evolving the Java Language
Filed under: javase7
Ever wondered why some cars are instantly recognisable ? Seen a new BMW in the last 25 years without twin headlamps ? Wondered how an SUV can still look like its a Porsche ? A Corvette a Corvette after over 50 years ?
Car designers, of course, follow certain design principles that keep the look of cars, especially their luxury brands, distinctive across multiple evolutions of a successful model. While we may not be aware of what these principles are as we see a new model Volvo pass us on the freeway, we usually know its a Volvo before we could explain why.
So what is that tells you the first time you Java written say for Java SE 5 Tiger, the release where we evolved the language in several different ways, is still the Java you grew up on in JDK 1.2, only perhaps with some new enticing special sauce added ?
Just like the twin headlamps of BMW, we have design principles for the evolution of the Java language.
I was looking through some older presentations in order to write a new one, recycler that I am, and I saw a presentation that Graham, Gilad and Mark made last year at JavaOne about the evolution of the Java language (find it using the keyword 'Evolving' here). Here are the design principles, together with my own commentary, we use as we evolve the Java language:-
Reading is more important than writing
That is to say the code should be a 'joy to read' (I'd be ok with 'short and sweet' myself) and it should do what you would expect it to do. I suppose in that parallel universe where you write your methods and classes just once and they work perfectly as you'd intended and never need changing ever ever again, then I guess this principle might seem a little redundant. But, hello, we don't live there, and we every one of us has particular methods that have burnt a hole in our hard disk because we just can't ever seem to let them alone. Declarative power rules ok.
One language, with the same meaning everywhere
No flavors, dialects, slangs, pidgins or creoles allowed ! The rain in spain falls most definitely on the plain.
Simplicity matters
Or in other words, if the semantic model is clear, the language will be more productive to use. Naturally, this creates an instant tension when considering a new language feature: adding a feature is in itself a new complexity in the overall scheme of things. Something new to understand, something new to trip over, waste an afternoon on. Also known as less is more.
You only need look at C++ with its surfeit of features, each added individually no doubt for excellent reasons but collectively adding up to a big ol' heap of complexity, to understand it was evolving under a different design principle (giggle, 'more is less' ?) before its Java-like successor was named up north.
Over the course of a number of generations of evolution, you may only see the link between one generation and the next. A car's 2006 model may bear little visual relationship with the 1990 model. There are of course reasons to have to change those principles over time if forced by circumstance. (Used Audi anyone ?).
A factor in its longevity of the Java language will be the relevance of its design principles we use to evolve it. I hope these will keep us classic and yet hip for a long time to come. Hmm, maybe like the new Range Rover ? Ooh, or maybe a Bentley Continental ? ...
Posted by dannycoward ( Mar 06 2006, 06:29:19 PM PST ) Permalink Comments [2]
