Feature idea

[Richard Dale]

On Monday 17 December 2001 10:01 pm, Gregor Zeitlinger wrote:
> On Mon, 17 Dec 2001, Richard Dale wrote:
> > Here are my plans for Gideon Java support:
> > 3) Avoid Sun technology -'Java the Platform', such as
> > AWT/Swing/Beans/JPDA etc. Just stick to free software such as gcj or
> > Kaffe, and use the java language as a 'better C++' to write KDE and Qt
> > apps. In my opinion, there are too many license problems with Sun's
> > libraries, and I don't think they tend to be very well designed compared
> > with Qt/KDE for instance.
>
> sorry, but i didn't know of this licencing issue. could you give me a url?
Have a look at the GNU classpath project where they are implementing free 
software versions of AWT/Swing. To implement Swing, you need to implement 
undocumented apis which Sun could change at any time. Recently Sun have 
stopped an open source vendor of an EJB framework from calling their stuff 
'EJB', because they can't afford to pay the very high cost of EJB 
certification. So you could get past the undocument api stuff, and then find 
Sun want to charge you lots of money for Swing 'certification' (maybe only if 
you came up with a good implementation that might compete with theirs).

> and what is badly designed about java? I'm just wondering, because I'm
> looking for a platform/language for a new GPL application, which should
> run under Linux and Win. Is Java+KDE suitable for that?
I don't think Swing is well designed - for instance, Qt's slots/signals are 
much easier to code than clunky Swing event listeners. 

The debug format of .class files is badly designed because it has info in line 
number within class format. If you have to specify breakpoints to jdb as 
<classname><method name>, how do you set breakpoints in anonymous classes? I 
don't actually know. I've seen bug reports on the Eclipse IDE site about 
problems setting breakpoints in anonymous classes, so the inconvenient design 
of the .class file debug format can have an big impact. 

Other debuggers, such as gdb, have the debug info in line number/source 
filename format. When you implement breakpoints in KDevelop, someone clicks 
on the breakpoint and a signal is emitted with the line number, and source 
filename (as far as I can remember). But that makes it very difficult to get 
a front end to jdb working properly with gideon (there is a jdb front end in 
the cvs under 'javadebugger'). There is no architecture in gideon for 
determining which class you are in, when you click on a line in a source file 
- and I don't think there should need to be any.

-- Richard