Skip navigation

This is the fifth and last installment in my summary of the sessions I attended at JavaOne this year.

 

The previous installments covered Java futures, Java programming practice, concurrency, and JMX stuff.

Once again, the titles here are not always the ones that appear in the conference programme. I tried to undo the mangling that the Trademark Police typically impose on talk titles, so let me just state up front that Java, JMX, and JVM are trademarks of Sun Microsystems, Inc., and any other abbreviation beginning with J has a sporting chance of being one too.

Here are the sessions summarized in this installment:

The Garbage-First Garbage Collector
Jamming with Java: Making Music with JFugue and JFrets
Semantic Web for the Working Ontologist
General Session: Extreme Innovation (the Toy Show)


TS-5419, The Garbage-First Garbage Collector, Paul Ciciora, Antonios Printezis. Antonios (Tony) presented the "Garbage-First" Garbage Collector, nicknamed G1, which will be showing up in an update of JDK 6. This is an improved version of the CMS collector (also originally designed by Tony). The new collector is better because it does not fragment memory as CMS can, and it does not require tuning the sizes of separate memory areas as CMS does. The performance should also be better. What made this presentation work was the painstakingly-constructed diagrams, which really helped understand the underlying ideas.

Tony talks more about this in an interview on the JavaOne website.

TS-5263, Jamming with Java: Making Music with JFugue and JFrets, David Koelle, Matt Warman. JFugue is a very nifty system that allows you to represent MIDI sequences with strings. This is hugely easier to work with than the javax.sound.midi API. JFugue adds useful notions like repeated patterns, which can be submitted to arbitrary transformers. It supports tapping out rhythms using arbitrary characters and then applying a substitution that says for example that *means a snare drum eighth-note and . means an eighth-note rest, so ..*...*. is a pattern that hits the virtual snare drum on the weak beats in 4/4 time.

Pedant moment. The melody shown for Frère Jacques in the slides had a D instead of a C as the fourth note, which means it wouldn't work as a round.

JFrets builds on JFugue to provide an app that does guitar tablature. I don't have much to do with tablature but JFrets seemed pretty useful for those who do.

TS-5555, Semantic Web for the Working Ontologist, Dean Allemang. I generally try to fit in at least a couple of sessions that are completely unrelated to my professional activities, and this is one. I chose this one because, like many people, I'd heard the term "semantic web" being bandied about but I didn't have any real idea of what it meant. Also, I know Dean from way back.

I think this area suffers from frightening terminology such as "ontologies" and indeed "semantic web" itself. It sounds a lot more complicated than it actually is. Which is not to say that it is simple.

The basic idea as I understand it is that today we have this fantastic web of human-readable information. We'd like to build on that infrastructure to create a web of machine-readable information as well.

Some questions are rather easy for people to answer by browsing the web. For example: who were the speakers at JavaOne 2008? But programs can't easily answer such questions because the human-readable information on the web isn't formally structured. The Semantic Web would allow web pages to be structured in a way that allows a program to understand them, without needing to build logic into the program for each information set.

There's an obvious parallel here with web forms intended to be filled out by humans, versus web services APIs intended to be called by programs. I don't know enough about the area to be able to say whether this might mean there is a sort of rivalry between web services and the semantic web.

I found it possible not to be scared by the word "ontology" by mentally replacing it with "schema". An "ontology" represents a set of concepts and the relationships between them. Well if that isn't a schema, it's near enough to one for me.

One thing Dean stressed is that it isn't necessary for some standards body to create all the world's schemas. The semantic web includes support for mapping between the concepts of different schemas, for example to say that "address" in my schema is the same as "location" in your schema. Of course there could be subtle differences in the semantics (perhaps "location" can represent the North Pole while "address" can't), but you can still get a lot of useful work done even with these mismatches at the edges.

And that's enough about the Semantic Web to be able to avoid sounding stupid when talking about it at parties. This talk, and the fact of writing it up, has led me to discover some promising starting points for further exploration, of which the best I've found is an article called Giant Global Graph by Tim Berners-Lee.

Sun General Session, Extreme Innovation, James Gosling and guests. Also known as the Toy Show, this is the annual overdose of geekery where James shows all the latest nifty stuff. It also doubles as a good way for the conference organizers to persuade people to stay around for the last day of the conference.

Unusually, I was right there at 8:30am when the show was due to start, because I knew that the first item would be VisualVM, being demonstrated by Tomas Hurkaand my teammate Luis-Miguel Alventosa. Equal measures of pride and stress for them, I think, as they stood up and demoed their stuff in front of thousands of people in a huge dark auditorium. In the event, the demo went off perfectly, as did the other demos from this session. (Unlike the first general session of the conference, but the less said the better.)

If you use JConsole, you should check out VisualVM.

Among the many other nifty things in this session, I liked the contraption that Greg Bollella built to show off Real-Time Java.

http://weblogs.java.net/blog/emcmanus/archive/rtjcontraption.jpg

Little coloured balls circulate through the plastic tubes, occasionally encountering pinball flippers or a bean machine. Eventually each ball falls past a colour detector and into a sorter. The Real-Time Java system has to flick the right switches while the ball is in free-fall so that it ends up in the right bin. Plain Java wouldn't be up to the job (what if a garbage collection happened at just the wrong time?), but Real-Time Java is. The box at the bottom of the picture is Project "Blue Wonder", a collection of Sun technologies suitable for use in industrial control processes. You can see more details in the video of this part of the session.

But the thing that impressed me most, along with most of the people I was talking to, was the Livescribe smartpen. It records your pen movements as you write and can upload them to a computer to reproduce what you wrote. It records ambient sound at the same time and can upload that as well. If you go back to something you wrote and touch it with the pen, the pen can play back the sound from the time you were writing. You can also search through your writing on the computer (handwriting-recognition algorithms seem to have improved without bound since the last time I was paying attention) and play back there the sound from what you find. There were some other nice demos: drawing a toy piano keyboard, then having the pen sound the notes from the keys you touch; or touching a word with the pen and having it pronounce the equivalent word in Arabic. But even without these I thought the pen would be invaluable to anyone who has to take notes often, for example students. It's not even very expensive: $149.

Jeff bought one for his wife (one can't buy such trivia for oneself of course) and she's apparently very happy with it. The pen needs special paper, but I noted with approval that Livescribe will be making software available so that you can print it yourself if you have a good-quality printer.


Well that's it from me about JavaOne for this year. Back to more mundane blogging...

[Tags: javaone javaone2008 garbage_collection garbage_first jfugue jfrets semantic_web visualvm real_time_java rtsj livescribe smartpen.]

This is the fourth installment in my summary of the sessions I attended at JavaOne this year.

 

The previous installments covered Java futures, Java programming practice, and concurrency. This one covers JMX stuff.

Once again, the titles here are not always the ones that appear in the conference programme. I tried to undo the mangling that the Trademark Police typically impose on talk titles, so let me just state up front that Java, JMX, and JVM are trademarks of Sun Microsystems, Inc., and any other abbreviation beginning with J has a sporting chance of being one too.

Here are the talks summarized in this installment:

JMX Technology Update
Practical JMX Security Options
Designing Manageable Java EE Applications in a Clustered Environment

In the remaining installment, I'll cover all the other stuff that didn't fit into any of my neat categories.


TS-5199, JMX Technology Update, Jean-François Denise, Éamonn McManus. Hey, that's us!

  http://weblogs.java.net/blog/emcmanus/archive/eams-thinks-at-podium.jpg 

Jeff(Jean-François) and I have been a double act for the last few JavaOnes and we repeated that here. I presented JSR 255, the JMX 2.0 API, much of which I have described to death elsewhere on this blog. Jeff presented JSR 262, the Web Services Connector.

Since Jeff is a bit of a poker fiend he had the idea that this year's demo could be based on poker somehow. He found an open-source poker server called CSPoker, created by students at the Katholieke Universiteit Leuven. He encouraged them to create a JavaFX GUI for the server.

  http://weblogs.java.net/blog/emcmanus/archive/poker-table.jpg 

Then he concocted a scenario where I was an evil poker cheater found out through JMX instrumentation. Thanks to the Web Services Connector, this JMX instrumentation was accessible through the same web server that players use. Once my cheating was discovered, the Web Services Connector also allowed Jeff to write a VBScript program that would access the JMX instrumentation to detect my cheating and kick me off.

  http://weblogs.java.net/blog/emcmanus/archive/sunglasses.jpg 

We rehearsed this demo until nothing could go wrong, and foresaw every possible problem. Notice the yellow cable linking the two laptops - no way were we going to rely on the conference centre's network to function as it should. But of course something did go wrong. There was much less light in the room than when we rehearsed there earlier, and I couldn't see the keyboard with my sunglasses! Well, that was pretty minor as problems go, and I even got an audience laugh out of it.

We were pleasantly surprised at how well received this simple sketch was. Actual applause when I showed my cheater's hand of four aces! We'll be thinking about another instructive demo for next year's talk, if it's accepted.

(The photos here are from hundredstaken by Yuichi Sakuraba at the conference.)

BOF-5698, Practical JMX Security Options, James Gould, David Smith. This was a very good introduction to JMX security from people who have obviously worked closely with it. Unlike the technical sessions, I don't think the slides from the BOFs will be available on the JavaOne site, but if they show up on the web somewhere I'll certainly link to them.

The message I took away from this BOF was probably different from most attendees. Configuring JMX security is too hard. We designed everything around standard Java security, using a SecurityManager, policy files, and so on. But almost nobody uses a SecurityManager, and although we also provide ways of configuring security without one, they are either too basic or too hard. An area for us to work on.

BOF-4945, Designing Manageable Java EE Applications in a Clustered Environment, Jens Jensen, Peter Kristiansson. Jens and Peter are at Ericsson, and I've had some contact with them before on this subject. Peter (presenting alone) described their solution for handling configuration in a clustered app server.

In their solution, each instance (JVM) has an MBeanServer that exposes a read-only MBean view of a tree of configuration elements. These MBeans get their data from a configuration provider in each JVM. One of the configuration providers is the master and the others are replicas. Updating the configuration involves a console or other management client updating the configuration in the master provider, which transactionally updates the persistent store and forwards the changes to the other providers. When a configuration provider (master or replica) gets a change, it informs the corresponding MBean so the MBean can send a notification.

They use Shoal to manage the cluster of configuration providers. They use JSR 303 (Bean Validation) to express constraints on configuration items.


In the next and final installment I'll cover the remainder of the sessions I attended.

[Tags: javaone javaone2008 jmx shoal bean_validation configuration poker CSPoker.]

This is the third installment in my summary of the sessions I attended at JavaOne this year.

 

The previous installments covered Java futures and Java programming practice. This one covers concurrency.

Once again, the titles here are not always the ones that appear in the conference programme. I tried to undo the mangling that the Trademark Police typically impose on talk titles, so let me just state up front that Java, JMX, and JVM are trademarks of Sun Microsystems, Inc., and any other abbreviation beginning with J has a sporting chance of being one too.

Here are the talks summarized in this installment:

Let's Resync: What's New for Concurrency in Java SE
Experiences with Debugging Data Races
Transactional Memory in Java Systems
 

In the remaining installments, I'll cover JMX and miscellaneous other stuff.


TS-5515, Let's Resync: What's New for Concurrency in Java SE, Brian Goetz. It's well known by now that processors are not getting much faster, but they are getting much more parallel, so applications need to be parallel to exploit them. Brian suggests that the existing tools in java.util.concurrent are fine when you're dealing with a small number of CPU cores. But what about the future, when there may be hundreds or even thousands? "All the cores you can eat."

The answer might be a massive migration to functional programming languages, but assuming people stick with Java, they will need the Fork/Join framework being designed for Java 7. The basic idea is to facilitate a divide-and-conquer approach, where you divide your problem into subproblems, and those into subsubproblems, and so on until you have enough work for your cores. A nifty technique calledwork stealing makes this fill up available cores without requiring work-queue bottlenecks.

A class called ParallelArray will allow the expression of parallel tasks without having to code an explicit divide-and-conquer algorithm. The idea is that you can write something like this...

double highestGpa = students.withFilter(graduatesThisYear)
                            .withMapping(selectGpa)
                            .max();

...where graduatesThisYear is a predicate object and selectGpa is a transforming object. (This is one of the main use cases cited for closures, by the way.) The calls to withFilter andwithMapping just return new objects, but the call tomax triggers the whole computation of filtering and mapping in parallel. Very nice!

TS-6237, Experiences with Debugging Data Races, Siva Annamalai, Cliff Click. I was already familiar with most of the material in this talk, but I thought the most important message was this. You might be debugging your data races with println, or maybe with a hand-crafted ring buffer because println perturbs the timing and makes the race go away. You might be thinking that there must surely be a better way. But one of the world's leading experts on concurrency confirms that, although tools can help in some cases, in general you do still need to be able to do the println stuff.

TS-6316, Transactional Memory in Java Systems, Vyacheslav Shakin; Suresh Srinivas. The idea of Transactional Memory is that your programming language allows you to write things like this...

atomic {
    return map.get(k);
}

...and the system gives you the familiar ACID properties (well, maybe not Durability) in the face of other concurrent accesses. This can be implemented entirely in software or with hardware assistance. Hardware systems build on logic already needed for cache coherence. There are "weak" atomic systems where transactions are only ACID relative to other transactions, and "strong" ones where they are ACID relative to all memory accesses. The slides are a good summary of the domain and I'd recommend them to anyone who wants to get an idea of what it's about. Unfortunately they're not yet present on the developers.sun.com site but I'll update this entry when they are. (They'll probably be at this address.)


In the next installment I'll cover the sessions on JMX technology.

[Tags: javaone javaone2008 concurrencyfork/join transactional memory data races.]

This is the second installment in my summary of the sessions I attended at JavaOne this year.

 

The previous installment covered Java futures. This one covers Java programming practice.

Once again, the titles here are not always the ones that appear in the conference programme. I tried to undo the mangling that the Trademark Police typically impose on talk titles, so let me just state up front that Java, JMX, and JVM are trademarks of Sun Microsystems, Inc., and any other abbreviation beginning with J has a sporting chance of being one too.

Here are the talks summarized in this installment:

More "Effective Java"
Defective Java
Using FindBugs in Anger

In the remaining installments, I'll cover Concurrency, JMX, and Miscellaneous others.


TS-6623, More "Effective Java", Joshua Bloch. This talk was excellent but I didn't learn all that much from it that I didn't already know. The one new thing that I took away is thatif you want to implement the smelly singleton pattern in Java, the best way is now to declare an enum with just one constant.

Pedant moment. Josh claimed that there is no term for a group of eleven musicians (like septet for seven or dectetfor ten), which I took as a challenge. The logical term, given that the Latin for eleven is undecim, should beundectet, and indeed Google finds a fair number of hits for that. It's true that most of them do seem to be from the same source, but not all. In the bookJosh says there is no standard term, and I think it would be hard to argue with that.

Speaking of the book, copies of it fresh off the press were selling like hot-cakes at the conference. I came home with one, after nearly losing it on the plane, and it is of course first class.

TS-6589, Defective Java, Bill Pugh. Subtitled "Turning WTF code into a learning experience". Of course the Trademark Police made it into "Defective Java™ Code", but they would, wouldn't they.

This talk covered a number of bug patterns that the indispensable FindBugs tool knows about. Bill and his coconspirators have been very good about building a catalogue of these patterns from all sorts of sources. He's made a habit of grabbing mistakes wherever he sees them, including ones he makes in his own code that he immediately notices just after typing them! I'm reminded of Knuth's massive TeX bug log, except that here the errors are captured in a machine-understandable form, to prevent other people from making similar ones.

I was mortified to see that one of the bug examples was from the JMX implementation in the JDK, in some code that hasn't been touched since 2000. The bug pattern is synchronizing on the value of a field to protect an assignment to that field...

synchronized (sequenceNumber) {
    sequenceNumber = new Long(sequenceNumber + 1);
}
 

I'd actually stamped out a bunch of other occurrences of this sort of thing, but missed this one. It's actually completely harmless, but embarrassing. Well, I didn't lose any time logging abug report and fixing it in JDK7, along with lots of other potential problems reported by FindBugs.

TS-6590, Using FindBugs in Anger, Bill Pugh. In this follow-on talk, Bill talked about some practices that are useful when using a tool like FindBugs on big code bases (>100,000 lines). There's a law of diminishing returns, and you need to decide how much effort to invest in this approach. Bill suggested concentrating on high and medium priority warnings, and on certain categories (notably "correctness"), which depend on your code base. He discussed practices to avoid having to wade through the same error reports every time you make a change. There was more in this very dense talk than I want to summarize here, so I'd encourage those interested to check out the slides.


In the next installment I'll cover the sessions on concurrency.

[Tags: javaone javaone2008 findbugs undectet java effective+java.]

I was at JavaOne again this year, and this time I found time to go to a surprising number of talks. I started writing a summary of them but it grew to about six screenfuls, so I decided to post it in installments. Here's the first installment, covering the talks about Java futures.

 

The titles here are not always the ones that appear in the conference programme. I tried to undo the mangling that the Trademark Police typically impose on talk titles, so let me just state up front that Java, JMX, and JVM are trademarks of Sun Microsystems, Inc., and any other abbreviation beginning with J has a sporting chance of being one too.

Here are the talks summarized here:

Upcoming Java Programming-Language Changes
Closures Cookbook
Modularity in the Java Platform

In the later installments, I'll cover Java programming practice, Concurrency, JMX, and Miscellaneous others.


TS-5581, Upcoming Java Programming-Language Changes, Alex Buckley, Michael Ernst, Neal Gafter. I was one of the reviewers of this talk so I already knew what would be in it, but I went anyway and was not disappointed. The presenters started with an excellent presentation of principles to apply to language evolution. These argue for a conservative approach to new language features; since I'm a Language Reactionary I was happy about that.

They followed with two proposals for exception handling. Withmulti-catch, you could write...

try {
    ...
} catch (IOException, IllegalAccessException e) {
    handle(e);
}

...instead of having to duplicate the handle(e)logic in two different catch clauses. (The syntax with a comma mirrors the throws clause but a syntax with a| is also a possibility.)

With rethrow the compiler's logic for determining the type of the variable in a catch clause is refined when that variable is final, so you can write...

void m() throws IOException, IllegalAccessException {
    try {
    // code that can throw IOException or IllegalAccessException
    } catch (final Throwable e) {
    handle(e);
    throw e;
    }
}

...and the compiler is smart enough to know thatthrow e can throw an unchecked exception orIOException or IllegalAccessException, but not any other Throwable, so you don't need to declare m() throws Throwable.

Either of these changes would be great for code that has to work with APIs (like the JMX API) that go a bit overboard with checked exceptions. I think it might be a bit redundant to have both, though.

After discussing module-related changes (about which more later), they discussed the extensions planned to annotation syntax via JSR 308. Many examples of what these extensions will allow were presented. (JSR 308 itself does not define these annotations but JSR 305 will, or others like them.)...

List<@NonNull String> strings;

class UnmodifiableList<T>
    implements @Readonly List<@Readonly T> {

These annotations can be processed by compiler plugins ("annotation procesors"), which can implement complex analysis of program logic to check, at compile time, that the assertions implied by the annotations must be true. So for example...

Graph g = new Graph();
// ...add nodes and edges...
// now g will no longer change:
g = (@Immutable Graph) g;

If the compiler (with its plugins) cannot prove thatg will indeed no longer change at the point of the cast, no matter what happens afterwards, then it will produce an error.

Finally, the presenters listed some other areas where the language might evolve in the longer term, such as better support for delegation (forwarding) and for parallel algorithms; and some areas where it probably won't, such as operator overloading and dynamic types. Here as in many other places it was emphasised that the Java language is just one way of using the JVM and of course other languages can target the JVM with their own feature sets.

TS-5579, Closures Cookbook, Neal Gafter. Neal gave a very good exposition of what closures are about before narrowing down on one particular application in a great deal of detail. From that example you could certainly see why closures might be useful. But as I mentioned, I'm a Language Reactionary, and I felt that Josh Bloch captured the issues admirably in his JavaPolis talk. Plus, I don't think the Closurists are doing themselves any favours with the Syntax From Mars.

TS-6185, Modularity in the Java Platform, Alex Buckley, Stanley Ho. Probably every Java programmer who's worked on non-trivial projects has encountered the problems mentioned here. First, if a module contains more than one package then there's no way for those packages to share classes and methods without making them visible to everybody else as well. Second, if your application needs two different versions of the same module because of dependencies from other modules, you are in trouble.

These problems are being addressed by JSRs 277 (for the runtime module system) and 294 (for the Java language changes), though as I understand it the two Expert Groups have merged so there's really only one JSR.

The language will acquire a new module keyword, although through cleverness it is not a reserved word and existing programs that use module as an identifier will continue to compile. The module keyword has two purposes: first, you can put a module declaration before the package declaration in a source file, to say what module the package is in; and second, you can declare the access of a class, module, or field to be module, which means it is accessible from any package in the module but not from outside the module. public continues to mean accessible from anywhere. An example from the talk illustrates this...

module  org.netbeans.core;
package org.netbeans.core.utils;
module class ErrorTracker {
    module int getErrorLine() {...}
}
 

Information about modules can be expressed using annotations like @Version and @ImportModule in a newmodule-info.java file.

The runtime module system will include a module file format (JAM), that captures this information; a new ClassLoader model that knows about modules (and is not fazed by the same classname appearing in different module versions); and a framework for module repositories, where there can be different implementations of repositories, such as a directory containing JAM files or an OSGi container.

My perception of JSR 277 was fairly confused until recently, and I think that might have been because the JSR itself was confused; but the JSR and I now feel much better, thank you.

I also went to the associated BOF, where among other things we got to see a demo that used the new JMX model for modules, designed by my JMX team-mate Shanliang Jiang.


In the next installment I'll cover the talks on Java programming practice.

Update: the PDF slides for the various sessions have begun to appear on developers.sun.com so I've updated the links here to point to that site.

[Tags: javaone javaone2008 closures java jsr277 effective+java.]

Next week is JavaOne 2008! I'll be speaking there with Jean-François Denise, about upcoming developments in JMX technology. Here are some of the other sessions you might want to attend if you're interested in that.

  • BOF-5552, "Java Observability by Bytecode Instrumentation", K Balasubramainan and A Sunararajan, Tuesday 7:30pm, Esplanade 300.

    How to attach to an already-running JVM and insert instrumentation code into it. Not necessarily directly related to the JMX world but of interest nevertheless.

  • TS-5199, "JMX Technology Update", E McManus and J-F Denise, Wednesday 4:10pm, Esplanade 304/306.

    That's us! I'll be talking about some of the changes to the JMX API being planned in JSR 255, and Jean-François will be talking about the Web Services Connector being designed in JSR 262.

  • BOF-5698, "Practical JMX Security Options", J Gould and D Smith, Wednesday 6:30pm, Hall E 134.

    Although we've put a lot of effort into make JMX technology secure, it's always possible to get your configuration wrong and leave yourself inadvertently open. It looks as if this BOF will show some good ways to avoid that.

  • LAB-1430LT, "Java Hotspot VM Trouble Shooting Tools in a Nutshell", M Li and J Shen, Thursday 12:30pm--2:30pm, Hall E 132.

    This hands-on lab is full but you might be able to sneak in. It promises to show you how to use JConsole, jps, jmap, jhat, and hprof.

  • TS-6145, "Using DTrace with Java Applications: Bridging the Observability Gap", J Haslam and S Ritter, Thursday 1:30pm and Friday 2:50pm, North Mtg 121.

    DTrace is an excellent piece of technology that allows you to add probes to an application and summarize the data they provide, by writing scripts in a special language. The application itself doesn't need to be modified to add the probes. DTrace is available on Solaris 10 and on Mac OS X Leopard, at least.

  • BOF-4945, "Designing Manageable Java EE Applications in a Clustered Environment", J Jensen and P Kristiansson, Thursday 7:30pm, Hall E 134.

    This looks to be a very interesting BOF for JMX weenies. The presenters are from a telecoms background but their abstract promises broad applicability.

  • BOF-5223, "VisualVM: Integrated and Extensible Troubleshooting Tool for the Java Platform", L-M Alventosa and Tomas Hurka, Thursday 7:30pm, Gateway 104.

    If you haven't seen the excellent VisualVM tool, this is the occasion to discover it. A simplistic way to describe it is that it is like JConsole but with added support for CPU profiling and heap walking, and the ability to download plugins from a plugin centre. Unfortunately this BOF clashes with the previous one.

  • TS-6028, "Near-Real-Time Distributed Enterprise Infrastructure for Traffic Data Collection...", J Carroll and B Smyth, Friday 2:50pm, Hall E 134.

    The JMX API is just one of a bunch of APIs mentioned in the abstract so I don't expect it to be the focus of the talk, but the subject looks pretty interesting anyway.

In addition to all that, Sun's Pod 136 in the Pavilion area will be staffed by JMX experts a lot of the time. Catch me there on Wednesday and Thursday from 11:15am to 2pm. Jean-François is likely to be around then too, if you have Web Services Connector questions. And Luis-Miguel Alventosa will be there in the same time-slot on Tuesday and Wednesday if you have questions or comments about JConsole or VisualVM.

See you there!

[Tags: javaone javaone2008 jmx]