Wednesday Apr 19, 2006

Speaking in many tongues



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.

<script type="text/javascript" language="javascript"> var sc_project=1489065; var sc_invisible=1; var sc_partition=13; var sc_security="6524bbfd"; </script> <script type="text/javascript" language="javascript" src="http://www.statcounter.com/counter/counter.js"></script>

Thursday Mar 30, 2006

Don't let the language choose you



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
... then you're definately inclined to be a static typer.

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.


<script type="text/javascript" language="javascript"> var sc_project=1447348; var sc_invisible=1; var sc_partition=13; var sc_security="e70e42a5"; </script> <script type="text/javascript" language="javascript" src="http://www.statcounter.com/counter/counter.js"></script>

Thursday Mar 23, 2006

The 10 Things You Need to Know About Java SE 6 'Mustang'



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 !

<script type="text/javascript" language="javascript"> var sc_project=1447369; var sc_invisible=1; var sc_partition=13; var sc_security="7131aa0b"; </script> <script type="text/javascript" language="javascript" src="http://www.statcounter.com/counter/counter.js"></script>

Friday Mar 10, 2006

Crash Course: Java SE Monitoring, Management and Troubleshooting



(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.


Monday Feb 27, 2006

Java SE 6: Mustang and WS-TMI



Did you know that Java SE 6, Mustang, features a subset of the Java EE Web Services stack ?

I've been tinkering with it, check it: Its JAX-WS (JSR 224) with a helping of JAXB (JSR 222) for its data binding, a good dollop of WS Metadata Annotations (JSR 181), with a sprinkling of a few of its own. Of course you've already teased a coulis of XML strained with WSDL in a JAX-RPC boullion with sun-dried MTOM/XOP and hand-crushed swaRef...

Yawn, W H A T E V E R . Too much information. Way.

Let's try it this way around....you have a neat little program, see ? It does something cute like adding a couple of numbers, which is self-evidently your market-dominating online service in thin disguise:

public class NumberAdderUpperer {

   public int addNumbers(int number1, int number2) {
        return number1 + number2;
    }
}


And naturally, you know you want to tell all your friends to use it, so in Mustang, they made it so you can do this:

import javax.jws.WebService;

@WebService
public class NumberAdderUpperer {

   public int addEmUp(int number1, int number2) {
        return number1 + number2;
    }

}


OK, so now you'd hit deploy in your IDE of course and stick it on the corporate app server, tell the world, and be done. But for the slightly more cautious amongst you, let's you and I do it with nothing more than the Mustang SDK, which has its own mini-Http server just for things like this:-

      import javax.xml.ws.Endpoint;
            ... 
        Endpoint.publish("http://localhost:8080/ws-tmi/adderupperer", new NumberAdderUpperer ());


Oops ! And now your new number adding service is published at:  "http://<hostname>:8080/ws-tmi/adderupperer".

Could it BE any easier ? (actually, maybe you think it could - let me know....)

And I did mention that adding numbers is an incognito book ordering or drug prescription authorisation service, and your soi-disant friends unmasked: they're your customers or patients, right ?

Ya, two imports and an annotation: that's the kind of simplicity I can go for.



About

dannycoward

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today