RE: java getting old?

["Bryant, William" <mbryant@c-cor.net>]

Just a couple general comments regarding Elliotte Rusty Harold's '10 Reasons
We Need Java 3.0'...

I do agree that the deprecated classes, fields, methods, etc. should be
removed (Rusty's reason #10).  While, for the most part, I guess it doesn't
_really_ hurt anything for these deprecations to still be there, in may
cases it could lock the language into a specific design/implementation.  In
order to redesign something they have to come up with a new class, leaving
the old one as is but with everything deprecated.  Just look at
java.util.Date and java.util.Calendar.  I'm not advocating that all the
functionality of Calendar should have been put into Date, I just offer it as
an example.  

This is reminiscent of Microsoft's still having DOS compatibility up to
Win2000 (and partially into WinXP) for fear of losing backwards
compatibility.  It's great to still run WordStar, but what hurdles have they
had to jump through in order to get it all to work?  Perhaps that is
partially why Microsoft operating systems are so prone to crash?  I do
realize that backwards compatibility is often needed, but for the most part
I do agree that it is time to cut the cord.

Regarding Rusty's number 9 (wait, just got inspired and had to insert the
White Album into my CD player...), the naming conventions are a bit of a
hassle at times.  Where I definitely agree with him is in the last paragraph
of the number 9 section: the fact that JDBC is part of the core language.
It's not JDBC in particular that concerns me, but rather that everything
these days is finding its way into the core language.  This worries me, as I
prefer to have the core language, well, core.  If I need JDBC/JNDI/whatever
I can just add it to my class path and use it.  I know that there could very
well be issues with that approach as well-- huge issues with backward
compatibility for one-- but those same issues could well exist with the
kitchen-sink approach as well.  I realize that this could indeed quickly
become an issue hotly debated, so I won't push it...


Well, my $.02, just some thoughts to further the discussion.


... Mike



-----Original Message-----
From: pommele@mindspring.com [mailto:pommele@mindspring.com] 
Sent: Tuesday, August 20, 2002 10:42 AM
To: ajug-members@ajug.org
Subject: java getting old?


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