[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sc-dev] Re: [win32] discard SCSpawn?

> > > No Java please.
> > What is the problem with java? Performance? Resources? Well, I dont
> > know, is this really an issue with the majority of things you do?
> >
> resources, yes. performance not that much tho.
> latest versions are not that sluggish any more but still demand quite
> some system resources.

can you be more precise please ? the JRE installer is big, that's true. but that's about all. let me as a java fetishist list a few of the pros:

– pluggable look-and-feel with very suitable laf's for all platforms
   (win xp, aqua, gnome) plus a few dozen more if you like fancy ones
– stuff like keyboard acceleraters, focus traversal, drag-and-drop
   can be easily added to the widgets
– there's a lot of interesting ready-made widgets plus models, for
   example customizable table and tree views, completely natively
   behaving file dialogs (java.awt.FileDialog) and requesters
   (javax.swing.JOptionPane) to name a few
– building custom widgets is very simple, just subclass an existing thing
   or a plain JComponent and write your own paint code in a few lines
   (i guess that's also possible with Qt though ?)
– performance is very good (have a look at how the current VMs work)
– well, you have the whole java API ;-)  you can easily add Java2D stuff
   for example, or go OpenGL or whatever you like ;
– stuff could be easily serialized and deserialized. it takes you dozen lines
   of code to write out your GUI as an XML file and reload it, etc. etc.
– if you *really* need to conditionally add some platform specific stuff,
   you'll jave JNI

> Java is ok for prototypes and applications that may need to run
> transparently cross platform but IMO only when this is the last
> resource.

sorry but that proves you've never really dealt with java. you will be able
to name a few bad examples, sure, but there's no point here starting
a serious discussion.

anyway, i'm happy with the cocoa classes, hehe ;-)

all in all the absolutely best solution would be to get harcoded class names
out of the supercollider GUI classes, so that as long as one agrees upon a
common API, the actual GUI server is exchangable.

ciao, -sciss-