WardCunningham wrote:

''Why don't you make a page about your class and then ask interested students to add a few comments about the class and/or language. I'd be interested in reading 1) their most pleasant surprise in the class, and 2) the most puzzling decision made by the LanguageDesigner''''''s. Let me try that myself ...''

I was pleased to see packages mapped to directories by strict rules, and that the compiler enforces/exploits this arrangement.

I'm continually puzzled that what seemed like a sensible exception mechanism requires so much busy work and still doesn't catch errors. ''(See JavaExceptionsAreParticularlyEvil.)''

----
I am pleasantly surprised by the way that reflection has become a central tool in the design of frameworks.

I am distressed by the lack of language support for aggregation. A lot of my objects seem to wind up passing messages along to their friends. Which requires a fair bit of typing and always makes me pause and think, "Why am I doing this typing?"

-- WilliamGrosso

----
I am pleased that they tightened up TypeChecking and at the same time provided an alternate mechanism for MultipleInheritance. Ditto threads.

I'm with Ward on the ExceptionHandling. I expect the ripple effect to start biting designers once they get into maintenance phase and start making mods. It's already hard on me. -- AlistairCockburn

----
I am pleased that some essential constructs, such as GarbageCollection, reflection, and separation of type and class, have reached the mainstream.

I am most disappointed at the lack of renaming (e.g.,
 import ... as ...
and "typedef"), and the weakness of some of the standard libraries.

-- SteveFreeman

----
I think the most striking feature of JavaLanguage is that EverythingIsaReference. This is sort of good and sort of bad, but I generally come out in favour of everything being a reference.

[''Almost'' everything is a reference - primitives are not, which is probably just as well because it's pretty memory inefficient to store small data as references and primitives are the smallest. -- JamesHollidge]

Since Java now has JavaGenerics, and even ChainedExceptions, there's not much about Java-the-language you can point to as bad, apart from its overall chunkiness. Java-the-platform still has a way to go. I suppose you could point to the access mechanisms (public/protected/private) as not being 100% good, because occasionally I, and even Sun, have had to make a method public even although it should have been package-protected, because the classes that need to call it are in a different package. If there was a "packageinternal"-type modifier which allowed access to any package in the same general area of the package hierarchy, but not to completely different packages, that might be nice.

[Sounds like a 'friends' construct to me - I'm sure SunMicrosystems will probably take that from CeePlusPlus too ;) -- JamesHollidge]

''Concur. What if a class could belong to more than one package? You could keep the TreeStructure naming convention for packages, but use package directives to define multiple memberships. You could define packages that described/explained the relationship between certain classes as needed. Or think of it the other way. One class can show up in multiple packages. OnceAndOnlyOnce. -- EricHodges''

MetaClass''''''es would be nice. I'm not a big fan of hidden statics. If we could subclass Class, life would be a lot easier. -- RobertDiFalco

----
I am pleased to use a language that's almost as powerful as CeePlusPlus, but not nearly as dangerous: it's essentially impossible to corrupt memory with JavaLanguage.

InnerClass''''''es are a perversion. [JavaInnerClassesArePerverse] Why not code blocks or method pointers? [See also BlocksInJava.]

-- JeffGrigg

I'm guessing that method pointers aren't going to be provided because SunMicrosystems is striving for a purely ObjectOriented platform. Of course things like '''static''' methods are more like procedures placed in a namespace - since there's no instance context it wouldn't seem unreasonable to be able to reference to it. That we can't is probably because having multiple first-class entities would screw up the VirutalMachine's/Sun developer's model of things. -- JamesHollidge

----
I am pleased by the Java security model in general and the JavaSecurityManager in particular. I like to be able to run code not trusted by me.

I'm puzzled by the lack of easy-to-type closures. I know that Java InnerClass''''''es can be closures, but they are a pain in the ass to write.

-- AurelianoCalvo

I dunno, maybe I've just gotten used to them but I seem to find myself writing this sort of thing all the time:

 new Thread(new Runnable() {
   
    public void run() {
      System.out.println("Meh.");
    }

 }).start();
Although I'd almost certainly refactor if it got more complicated than a few lines of method code. And closures are probably preferrable to creating a slew of new classes for Action''''Listeners and the like.

-- JamesHollidge

Well I've actually written something like this on a real application:
 new ActionListener() {
   public void actionPerformed( ActionEvent e) {
     new Thread( new Runnable() {
       public void run() {
         doSomething();
       }
     }).start();
   }
 }
or was it using the Foxtrot library? I don't remember. But I remember the awkward feeling to see an AnonymousInnerClass inside another anonymous inner class. I write closures inside closures in RubyLanguage and it seems nicer. Certainly, it requires both less typing and fewer syntactical components! -- AC

That looks astonishingly familiar - probably because I did something entirely similar! It's kinda convenient for a delayed action on a GUI component by getting the thread to sleep for a bit. -- JamesHollidge