RE: java getting old?

["Stefan Baramov" <s_baramov@bellsouth.net>]

I've read the article too and there are some great ideas and some not so
great. On your four point I can comment on the first two.

On 1) I think we have enough keywords so adding a new one will bring
confusion and uncertainly. You can't replace ejb-jar.xml with one keyword
can you? If you look at xdoclet.sourceforge.net you might find a better
solution there.

2) 100% agree! Although well designed Swing is slow and heavy. Thread
expensive and has memory leaks. And after all Swing Look&Feel doesn't fit on
XP Look&Feel. The OS are getting skinable lately including Windows XP,
MacOS, Gnome and KDE and having an application with a different a different
look&feel seems at least unprofessional.

regards,
stefan baramov

|-----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
|
|