Thursday Jun 15, 2006

Solaris vs. Linux in the Large Enterprise

Here's an excellent, balanced article on Solaris vs. Linux in the large enterprise.

Wednesday Jun 14, 2006

NetBeans Runtime Container

A very nice article on using core, non-visual portions of NetBeans (termed the NetBeans Runtime Container) outside of the NetBeans IDE. Foremost among several advantages to using the NetBeans Runtime Container is the ability to use the NetBeans module system, which is a very powerful and dynamic way of modularizing your application code.

Friday Apr 07, 2006

Re: I've been promoted to Chief Architect of Java Enterprise Tools

I forgot to mention that the extremely talented Chris Webster will be stepping into the role of XML tool architect now that I have a broader scope.

Thursday Apr 06, 2006

I've been promoted to Chief Architect for Java Enterprise Tools

I've recently been promoted to the position of Chief Architect of the Java Enterprise Tools product group at Sun. Charles Beckham, the previous architect, will be moving on to direct the architecture for all Java tools, and I will be reporting dotted-line to him, as will the architects of NetBeans and Creator.

I don't yet know all the changes this new position will bring, but I know one thing: it's not going to help me find more time to blog. <g>

Windows on Mac, a couple issues

Last night I installed Windows XP Pro on a brand new MacBook Pro using Apple's Boot Camp, but there are a handful of small but significant issues that prevent me from using it as a Windows machine comfortably.

  1. There is no way to generate a right-click in Windows using the MacBook's single mouse button. An external mouse can solve this, but it's inconvenient. Software can also fix this by adding the ability to use a key modifier for mouse clicks, but I'm not aware of any software available.
  2. Macs have a Delete key, which actually corresponds to a Backspace key on a full keyboard. There is no equivalent to the Delete key on a full keyboard. This means that there is no way to delete files from Explorer, delete objects in various programs, etc. without right-clicking and choosing a Delete action from a contextual menu. This is aggravated all the more by by issue (1); on a plain MacBook, you can't effect the desired behavior in any way. This is a serious drawback, and although software can remap the key, you would then lose the Backspace functionality. In case you're wondering, Ctrl/Alt/Option/fn+Delete dosen't result in any helpful behavior. A reasonable solution might be to add a key combination like Ctrl+Delete through software to generate the right key code, but that will be about as annoying as holding down another key while clicking the mouse.
  3. Ctrl+Alt+Delete doesn't work (since the Delete key is really the Backspace key), so if a process hangs it's not possible to get to the Task Manager (further aggravated by the fact that I can't right-click on the Task Bar to bring it up without an external mouse).
Unfortunately, Apple's general design approach of under-delivering on features in order to simplify (they give you about 80% of what advanced users really want, but that 80% works really well for the masses) screws us in the Windows world. Steve, just give us two more hardware buttons and we'd be quite happy to buy your hardware. I'll report more as I find other issues.

Saturday Apr 01, 2006

Global Name Uniquification at Sun

This memo was sent to all Sun employees today. I guess I'm lucky I have a unique name!
TO:        U.S. Employees
FROM:      Global Employee Name Management
DATE:      April 1, 2006
CONTACT:   Name Management x94678 (WHO-R-U)
ACTION:    Please read.

This bulletin contains important information about your name.

Overview

Sun has long had a requirement that every UNIX username inside Sun be
unique.  The transition to these globally unique usernames was at times
painful, but the result has been that Sun has been able to support a
level of global operation that is unprecedented.

It is now time to take that process to its next logical step:  Ensuring
that employees' names are unique.

Employees with duplicated names represent immeasurable opportunities
for confusion, wasted time, and security breaches.  In the interests of
improving the efficiency of the company, we are embarking on an
ambitious effort to improve this situation by making employees' names
globally unique.

Implementation

In the first phase, to be implemented between today and April 1, 2007,
approximately 800 employees with duplicated first and last names will
be renamed to eliminate the duplication.  At the completion of this
phase, it will be possible to uniquely refer to any Sun employee using
the employee's first and last name.

In the second phase, to be implemented between April 1, 2007 and April
1, 2008, approximately 20,000 employees with duplicated first names and
last initials will be renamed to eliminate the duplication.  At the
completion of this phase, it will be possible to uniquely refer to any
Sun employee using the employee's first name and last initial.  In
addition to the obvious convenience improvement involved, substantial
savings are expected through eliminating printing the full last name on
various internal documents.  The ink required to print a typical name
will be cut in half!

In the third phase, to be implemented between April 1, 2008 and April
1, 2009, all employees at the Vice President level and above will be
renamed so that their first and last initials are unique.  Employees at
the E/Z-10 level will be renamed so that their first, middle, and last
initials are unique.  In addition, in each Director-level group and
each building, all employees will be renamed so that their first,
middle, and last initials are unique.  At the conclusion of this phase,
it will be possible to refer to any highly visible employee using only
two or three letters, and to any employee in a particular organization
or physical location using only three letters.  In the vast majority of
cases, use of initials should be sufficient to identify an employee.

New Employees

New employees will be required to conform to the naming requirements in
effect on their start date.  If required to pick a new name, they will
be encouraged to take the future naming requirements into account in
their choice.

Conflict Resolution

In general, the employee with the lower badge number will retain the
original name, and those employees with higher badge numbers will be
renamed.  The employee will be allowed to choose a new name, but if the
employee is not able to decide on a suitable name before the deadline,
a new name will be assigned in consultation with the employee's
manager.
        
    

Thursday Nov 17, 2005

JavaOne 2005 Speaker Award for Coding Across Continents

I have been awarded a 2005 JavaOne Conference Speaker Award for my presentation, Coding Across Continents: Technologies for Remote, Real-Time, Collaborative Software Development. My session was rated among the top 20 presentations in overall quality by JavaOne attendees. Thanks everyone for the feedback!

If you are a Sun Developer Network (SDN) member, you can watch and listen to my presentation online. (If you are not yet an SDN member, registration is free.) Once you've seen the presentation and are ready to begin building collablets for the NetBeans IDE, head over to http://collab.netbeans.org for more information.

Tuesday Aug 16, 2005

A NetBeans Song

Roumen has very bravely written and recorded what I believe is the first NetBeans song! Please check it out, and don't forget to follow along with lyrics while you listen to the song.

Tuesday Jun 28, 2005

Building Collablets

If you get a chance, please join me for my technical session, TS-7302, Coding Across Continents: Technologies For Remote, Real-time, Collaborative Software Development. I'll be talking all about NetBeans developer collaboration and will show you how to immediately add new collaboration capabilities to NetBeans by walking you through building and installing a new collablet in the IDE.

Sunday Jun 26, 2005

Collaborate!

Alexis clearly has more time than I do now to evangelize developer collaboration! Please check out his excellent post describing our open-source announcement of developer collaboration for NetBeans today. Thanks again, Alexis.

Must-Attend Session: A Hitchhiker's Guide to SOA

Please join me for what will be the funniest technical session at JavaOne 2005: TS-7121, A Hitchhiker's Guide To SOA: Orchestrating Loosely Coupled J2EE Services with BPEL & BPMN. Not only do we have a very entertaining presentation (unlike most JavaOne sessions <yawn>), but we'll also be giving a very meaty demo and lots of info on SOA, BPEL, BPMN, and building loosely coupled Web services. If you want to learn about any of these topics or just want to be entertained after a long day of boring sessions, don't miss it.

The Big Announcement: NetBeans Collaboration Project

If you were at NetBeans Day, you saw me give a demo of the just-open-sourced NetBeans collaboration project. I'll certainly blog more about the project later (still busy preparing for yet another demo tomorrow), but one of the biggest laughs during today's keynote came when Jonathan Schwartz prompted what appeared to be a scatterbrained presenter--me--to make the announcement about Java Studio Enterprise's collaboration technology going open source. But, I have to set the record straight: everyone told me that he was going to make the announcement, so I was trying to avoid doing so! In any case, it was great for a laugh and no harm done.

If you get a chance, please join me for my technical session, TS-7302, Coding Across Continents: Technologies For Remote, Real-time, Collaborative Software Development. I'll be talking all about NetBeans developer collaboration and will show you how to immediately add new collaboration capabilities to NetBeans by walking you through building and installing a new collablet in the IDE.

Monday Jun 13, 2005

Creating Nested (Complex) Java Annotations

When creating new annotations, it doesn't take long to get to the point of wanting to use what are referred to in the JSR-175 specification as complex annotations. Before we talk about complex annotations, as a reminder, non-complex, simple annotations look like this when used:

@SimpleAnnotation(a="...", b=3)
public Object foo() {...}
In this simple case, annotation members are scalar values, in this case "..." and 3.

By contrast, complex annotations may contain other annotations in a nested fashion. They look like this when used:

@ComplexAnnotation(
    @SimpleAnnotation(a="...", b=3)
)
public Object foo() {...}
Complex annotations can also define arrays of members too:
@ReallyComplexAnnotation(
    { @SimpleAnnotation(a="...", b=3), @SimpleAnnotation(a="...", b=4) }
)
public Object foo() {...}
Let's look at the declarations for the annotations above. The simple annotation is pretty straightforward:
@Target(ElementType.METHOD)
public @interface SimpleAnnotation {
    public String a();
    public int b();
)
The declaration of the first complex annotation example above is the following:
@Target(ElementType.METHOD)
public @interface ComplexAnnotation {
    public SimpleAnnotation value();
)
This is not too much different at first glance, but note that the type of the member value is now an annotation itself. This is how complex, nested annotations work. In fact, it's illegal for an annotation to declare a member that is not either a simple type (int, float, String, etc.) or an annotation. For example, you can't define an annotation that returns java.lang.Object. The reason for this is that annotation values must be constant expressions to the compiler, and there is no way to express an instance of java.lang.Object in source code such that it can be statically evaluated by the Java compiler. (You might at this point argue that string literals in source code can be concatenated with plus signs--doesn't that result in a non-constant expression? No, it doesn't. This is actually a trick of the compiler; it statically concatenates string literals at compile-time, so in the compiled code there is no difference between "ABC" and "A"+"BC".)

Let's move on the the next example where we declare an array member:

@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation[] value();
)
Very straightforward; just add the square brackets onto the type, just like you're used to doing elsewhere in Java code.

Now here comes something a bit trickier. Annotation members can have default values so that users of the annotation don't need to specify a value for a member in every annotation. In this sense, the member value is optional in that it can be omitted by the user of the annotation, though the value will be the default specified by the annotation type. The way to declare this is quite easy:

@Target(ElementType.METHOD)
public @interface SimpleAnnotation {
    public String a();
    public int b() default -1;
)
Now, the user of the annotation can leave out the value of b, in which case its value will be -1:
@SimpleAnnotation(a="...")
public Object foo() {...}
So far, so good. Now, what happens when we want to specify a default for an array member? The logical default for an array would be an empty array, but how do we express this? Based on your previous Java experience, you may be tempted to use one of the following:
@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation[] value() default new SimpleAnnotation[0]; // wrong!
)

@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation[] value() default SimpleAnnotation[0]; // wrong!
)

@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation[] value() default null; // wrong!
)
Each of these is incorrect, however. The first is not a constant expression (the keyword new necessarily indicates an expression that can only be evaluated at runtime). The second is simply not valid Java. The third, specifying null, though seemingly a constant expression, is always an invalid expression according to the JSR-175 specification.

Here's the proper way to declare the empty array:

@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation[] value() default {}; // right!
)
You should recognize this expression, though I admit it wasn't immediately obvious to me.

OK, now it's time for Final Jeopardy: how do you declare a default for a non-array annotation member? If you're like me, you're immediately tempted to specify null, because that's what we normally do in Java code. But, remember, null is always an invalid default expression according to the spec. Here are some variations you might try:

@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation value() default null; // wrong!
)

@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation value() default SimpleAnnotation; // wrong!
)

@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation value() default new SimpleAnnotation(); // wrong!
)

// arghhh!!
The compiler error for each of these attempts is "annotation value must be an annotation". This is utterly confusing at first, but does give you a hint. We need to return an annotation as the default, so how do we get one? How do we normally get other annotations? We simply type them:
@Target(ElementType.METHOD)
public @interface ReallyComplexAnnotation {
    public SimpleAnnotation value() default @SimpleAnnotation(a="..."); // right!
)
This seems completely counter-intuitive at first because we are using the "annotate X" syntax with the @ sign, but there is no apparent "X" to be annotated here. Furthermore, the target for the annotation seems to be ignored. Indeed, this seems like an inconsistency, but think of this syntax instead as specifying the annotation that will be used by default if no annotation is specified. If you think of it this way, it is pretty obvious how this works--it's as if the author had typed the default annotation in their code. Because everything is a constant at compile-time, there is no inconsistency in terms of specifying the annotation here instead of in the user's code.

Monday Jun 06, 2005

Colliding Worldviews: Kitty Hawk vs. Indigo

Over time, I've come to understand that there are two predominant worldviews, championed by Microsoft and Sun, concerning Web services and the role they play in relation to developers. Here are a few, high-level thoughts on the topic for your Friday-night enjoyment.

For Microsoft, Indigo and the WS-\* stack form the basis of their .NET and Longhorn OS platform. If you look at the role of each of the WS-\* specs embraced by Microsoft, it becomes clear that each one is primarily a formalization of patterns, conventions, best practices, and designs that have been in use for years, if not decades. There really is very little new about WS-\* except terminology and syntax. For Microsoft, however, these specs allow them to build an open architecture to support all the things they want to include as part of their platform. The key question to ask, however, is who are the users of this platform? I posit that Microsoft will be the primary consumer, at least in terms of direct interaction with the WS-\* technologies. For others, Microsoft will deftly hide all of these details (and complexity) underneath developer-friendly APIs and components that may or may not involve Web service message exchanges. Does the developer care? In Microsoft's worldview, the answer is no. For Microsoft, SOA is the platform.

Kitty Hawk and several Web service proponents at Sun think in quite different terms. Rather, we (meaning Sun, not necessarily me) tend to think in terms perhaps best described as SOA is the application. This is consistent with Sun's track record with J2EE. J2EE was a success precisely because it directly put the tools of distributed computing in the hands of developers. The fundamental premise of the old J2EE worldview, and perhaps now the Kitty Hawk worldview, is that distributed computing is something developers care about directly. This manifests in Web service terms as developers wanting to construct and controls precisely the messages sent over the wire. For productivity, they want APIs that are modeled closely on these specific tasks. Sun gives developers APIs to construct a SOAP message and invoke a Web service; Microsoft gives developers APIs to invoke a method on an object like any other, but which may be exposed as a Web service.

One might argue that Indigo is an ill-fated direction for Microsoft and that perhaps they are missing the boat. After all, their previous efforts to bring distributed computing technologies (DCOM) to the developer masses were, for lack of a better description, squashed by J2EE. J2EE was in large part a reaction to the fact that Microsoft, as the 800 lb. gorilla, either had nothing solving problems in the same domain, or hid everything so well that developers couldn't peek under the hood to go beyond existing limitations. J2EE made distributed computing available to everyone, and generally it has been easier (in terms of capability vs. complexity) and more transparent than the alternatives. One may also argue, however, that J2EE's prominence at the forefront of developers' minds is coming to a close, and that it is now an inelegant, complex morass that complicates more than complements developers' lives.

However, there is evidence to support Sun's worldview that developers care about the deeper levels of the platform. Today, armies of consultants and corporate developers are employed to build enormous distributed systems using J2EE as the foundation, and there is an enormous information market surrounding it. These developers live and breathe distributed computing as digested and presented by J2EE, and in general, it works. Clearly there has been something right about the approach Sun has taken with J2EE.

Back to Web services: Kitty Hawk seems inclined to treat SOA and Web services as both means and ends: Web services have value in and of themselves as the way to write applications. Indigo seems to shy away from this grand scheme and instead treats SOA and Web services as merely a means to a different end: helping developers write apps easily using the Microsoft platform. Is the worldview difference attributable then to motive? I don't think so. Sun has as much interest in perpetuating the Java platform as Microsoft has in perpetuating its .NET platform.

I think the answer is instead a matter of philosophy around developers and tools. Inarguably, Microsoft deeply understands software developers en masse (and arguably, Microsoft understands them better than anyone else). If there's one thing Microsoft does exceptionally well, it is satisfy developers by giving them terrific tools to make use of the Microsoft platform. As evidenced by Steve Ballmer's legendary "developers, developers, developers" speech (which I think, unlike some, was stunningly brilliant), Microsoft's commitment is to the developer and in giving him easy-to-use tools that make his job easier.

Sun, on the other hand, has been historically less committed to the idea of ease-of-use and tools as a means to Java platform adoption. Capability to write certain kinds of applications has been the driving force behind Java and J2EE, and Sun certainly understands the developers that write these particular types of applicationss quite well. If I'm being intellectually honest, I must also say that Sun has often fallen short when it comes to appealing to the broader developer community via tools. For many reasons, historical and otherwise, Sun has traditionally thought of tools and their place in the developers' universe quite differently than has Microsoft. If the desired end result is an application, tools are the primary means to this end for Microsoft. For Sun, APIs have traditionally been the primary means to this end (though this is rapidly changing).

So the big question: is there anything wrong with either of these two worldviews? Perhaps, but not necessarily; each confers both advantages and disadvantages. But, these differing worldviews lead to some interesting schisms. Take for example the notion of Web service conversation. In the Indigo worldview, conversation is session, likely tied to the notion of transport-level connection (or perhaps its analogue using WS-ReliableMessaging and WS-Transport) and spanning one set of interactions between client and service. In the Kitty Hawk worldview, conversation is a broader abstraction that gives additional meaning and context to business data across multiple sets of interactions between clients and services, independent of transport and session. Both perspectives are valid, but difficult to reconcile. They lead the broader Web services standardization effort down paths with different conclusions.

Which of these worldviews is superior, and which will inflame the minds of developers to drive respective platform adoption? I'm not going to try to answer such unanswerable questions. I don't think the future is yet written, and if the past is any indicator, there are reasons to believe that both worldviews are viable and can coexist. Perhaps they are best described as the opposite ends of a spectrum between which different developer communities swing like pendulums. Now that Sun and Microsoft are officially cooperating on Web service standardization and interoperability, I think the most important result of this discussion is simply understanding these different, perhaps reconcilable--but perhaps irreconcilable--perspectives on the shape the Web services universe should take.

Wednesday May 25, 2005

Advanced Configuration of Free-Form NetBeans Projects

Unlike other IDEs, the project and build system in NetBeans 4.x is thoroughly Ant-based. Users have the ability to create what we refer to as a free-form NetBeans project that points to an existing build script rather than a tool-managed build script. This very useful article by John Jullion-Ceccarelli and David Konecny describes advanced configuration of a free-form project to "achieve an even tighter integration between NetBeans IDE and your build process".
About

toddfast

Search

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