For these points, which IMHO are unfounded. please read the link :
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
Here are the points :
Also, using other libraries is simpler (C or C++ ones) and faster then using
them from within Java code, though it's possible.
Actually, on-demand class loading are much faster than library loading.
I did a lot of research on the Qt/C++ vs Java matter, but it seems that all
those people commenting on it on the net are rather "religious" about there
favorites, instead of pointing out which one is better for which task.
My plan to switch over Java is based on real experience in both C++ and
Java development, and not just "goggling". I am not a Java
enthusiastic. I am a "productivity"-enthusiastic. In real life I
work as software engineer, and that involves risk analisys.
Nevertheless, it seems to be a big issue that Java programs tend to be slow,
at least when used from within Linux systems, and although this may due to
less efficient GUI libraries, it's a common experience.
The only thing that java in linux is slow regards to GUI stuff, due the
factr it is based on gtk. But GUI usage is a smaller on our project,
when compared with other java tools for linux. Since we prefer direct
drawing of audio/clips, and also we created JMB, Gui resources will be
very few, so I dont think it will be big issue. In many other
points Java/linux is even faster than Java/windows, due the fact the
SUN has access to linux internals to make optmizations. Thats we notice
in big projects decisions. Most of corporative systems run in
application servers hosted on linux boxes.
Memory footprint is also larger, at least when you run the program in a JVM,
which would be the case. Compiling it to native code could be an option, then
it would consume less memory (no JVM required) and it seems the program wil
run faster (Redhat has compiled Eclipse to native code, and startup time went
from one minute to 15 seconds...)
read the article. Memory footprint, when you discard the VM, is much smaller than native code.
But then it makes less sense to switch over to another language since we
allready compile to native code, and we would throw away one of the featues
of the Java language...
no need to native compilation. JIT compilers does that on demand much
more efficiently than static compilers. Read the article or google for
"JIT vs native"
Anyway, using Java for Protux means we have to port both libmustux and Protux
to Java, and usage of the Qt toolkit becomes less usefull/apparent, so
effectively it means that Protux will become no longer a Qt program.
JavaQT is an alternative for us to avoid using AWT or Swing, since they
are the only critical point regarding performance. There are
other possibilities , like FullScreenMode, which allow us to work
directly into X space, on even OpenGL..
After asking a number of people (who did both Java and Qt/C++ coding) it
appears that Qt/C++ is the better choice since it simply runs faster, more
I have been working for more than 5 years with Java and C++/QT (Project
Shark for example), and I dont remember of being asked by you.. ;-)
memory efficient, and kdevelop as development platform is making huge strides
to become on par with the Eclipse development platform feature wise...
no comments on KDevelop. Anyone that uses eclipses know that there is no comparison.. Use both and compare yourself.
(Kdevelop has integrated Qt support, a fairly decent Make manager, both
automake and qmake, so compiling the program is only one click away, code
completion/management works rather well with kdevelop 3.2.2 and will be much
better with kdevelop4)
still no comments... if I had to compared, I would say that kdevelop is
to eclipse the same way the pico editor is to kdevelop.
I dicussed this proposal with Luciano, and agreed that using Java could speed
up development in some areas, but I'm worried about the time it takes to port
the whole project over, which is rather a large amount of work. So, my
question was: Is it worth the effort.
what is the problem about the time.. it is free software.. no deadlines :-)
Then the performance problems, linking to other non Java libraries, and the
issue the users will have to install the Java runtime environment to make
Protux run, which is not to my liking.
the users we target will probably be thinking about the audio
production they have to dispatch to their studios, rather than "oh my
god.. I have to install java.. a proprietary thing on my
computer.. arrrg".. They will probably use some distro with a good java
vm pre-installed.
Again, we are targeting end users, no linux-geeks. End-users installs
many proprietary stuff on their machines.. Java VM requirement is not a
big deal...
Actually, I had some ideas improving Protux and porting it to Qt4, since when
Protux will be more usable, Qt4 will be available on all distro's.
In fact, I did a quick test and it was easy to port it to Qt4, though a number
of painting problems had/need to be resolved...
You have not been assigned to evaluate that migration to QT4.
That is my role in the project. then, unfortunately, there is
nothing that I can do to compensate your work.
Well, as you allready guessed, I'm not too fond of the idea to port the
project over to Java, specially not since Qt4 has so much to offer, which we
can use right away.
If Luciano decides to switch over to Java, I'm not sure yet if I'll continue
to work on Protux. It depends a lot on how things will evolve if he decides
to do so.
That was very unpolite. link your participation with my decision.
Be sure that I will take decisions based on the project, not on
personal expectations.
since I planned to work on Protux,also on porting it to Qt4, which I was doing at the time this proposal came
Thats is very invasive. This is not your role in the project.
in. So, I'm in favor of keeping Qt/C++ as development platform :-)
Your vote has been registered.