java getting old?

[<pommele@mindspring.com>]

There was a thread a few weeks ago at slashdot about suggested future changes
to the java language.  It referred to this article:
www.onjava.com/pub/a/onjava/2002/07/31/java3.html

  I disagree with some of his points but an interesting read none the less. 
It got me thinking of what I would change. I was curious if others felt the
same way I do.  This is what I'd suggest:


1. Remote key word to replace ejb
One of the reasons that java was adopted so readily was the cleanly designed
language that was easy to understand, especially compared to c++.  I for one
am grateful that it has remained that way.  The exception to this in my
opinion is ejb.  To manager a single entity bean in ejb it requires you to
manager up to 6 files, the implementation file, local remote, local home,
remote, home and the descriptor.  This could be simplified by making rmi part
of the jvm and adding a new java keyword remote (sample below).  There are a
lot of implications to this, especially to ejb app vendors.  This wouldn't
cover transactions or threading so there would still be plenty of work for app
vendors to do.
C#.Net has something analogous to this called remoting I think.  Why not adopt
some new features from them.  
This could easily be made backwards compatible.

Public remote class SomeClass{
    public remote Object getSomething(){}
}



2. deprecate awt and swing and replace with an eclipse like swt and app frame
work (this is a library change not language change)
In my opinion swing is almost single handedly responsible for the java's
reputation as slow and fat.  Letting developers choose a look and feel that is
not integrated into the underlying platform was a huge mistake.  It make the
language look cheap and unprofessional.  
    Not only will making the widgets native integrate the app to the underling
platform, appearance wise, it will help performance and give the api's a
smaller foot print.
    Also the api designers need to consider and include an application centric
design.  I know this really only applies to mac users (like me) but if they
are truly going to be cross platform they need to accommodate different
application design models, also.
 


3. java kinds and drop assertions
    I for one really like that the language has remained simple.  I've toyed
with assertions just to check them out and in my opinion they really don’t
offer anything exceptions don't already do other than a coding convention.  It
would be language clutter to me.  Sorry if I've offended some one here.  Can
some one convince me otherwise?
    What I would really like to see is some mechanism similar to the C++ enum
to group data or objects in a none hierarchical way. I'm calling them "kinds" 
for a lack of a better term.  And somehow, if it could accommodate type safe
collections, that would be excellent.  It could probability be make into all
compile time checks.  And this also could easily be made backwards compatible.
    

Psydo code: 
Public kind SomeKind [data type or object]{   
    
    //list of kinds, in this case int
     public static final int x = 1; 
    etc.
}

Public kind SomeOtherKind MyInterface { }

Public someClass{

    // compile time check to see if it's a int of SomeKind
    public void setSomething(kind SomeKind someParam){}
    

    // I haven't really thought this one out for type safe collections
    public kind someOtherKink Collection getCollection(){}
}


But then again, maybe this would be clutter.


4. jsp deprecate scriplets (also just a library change )
Jsp was conceived before xml, as far as I know, and was originally intended to
compete with asp.  A lot has changed since then.  I think they should
deprecate scriplets and replace much of jsp with a jsptl, struts, coldfusion
style tag library that is well formed, valid xml.  They're already moving in
this direction, why not speed it up.


I hope this is taken in the spirit of appreciation for the language and that
these are suggestions. There are many people, a lot smarter people than me, 
working on the same thing.


Michael Fortin