Re: [Protux-devel] Possible Migration to Java
Hi, I read the links you gave, did some testing (benchmarks, just for fun) found in some of the articles. The benchmark was rather simple, not taking the OO into account, but only simple operations on int, long, double and trig functions (sin, cos, etc) They performed equally well, which is no surprise, but the sin, cos, etc functions performed an order (~ 10) of magnitude slower in Java, weird About the JIT, and JVM, what I understood is that for long running programs (which also create a lot of objects with short livetime) they can do a better job then statically compiled programs (due the better heap management), and so Java would be a better choice for server programs then C++ Please, correct me if I misunderstood... > > 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. Sorry, I don't understand. If you decide to switch over to Java, it means the project has to be rewritten, and after thats finished, new things can be implemented. That effectively means that I too have to write Java code, no? And I'm not a Java coder, sure, I'm not a C++ coder too but at least in that area I'm gaining a little experience. So, for me the question then arises, do I have time, energy and the spirit to start over again, and jump into Java stuff. It's not about linking my participation to your decision, but to the _effects_ of that decision. About the "personal expectations". OSS frequentlly suffers from the phenomena "project creation, big boost into development, developer time or interest becomes less, project dies" It's not a secret you don't have much time last years, and you said yourself you still do have little to no free time. I have seen the birth of this project, and I was really excited about it. I looked very frequently on the website, but after 2 years almost nothing had happened. Then I tried to help by improving some code. That's 2 years ago IIRC. The project is 5 years old now, and the last 4 years showed little improvement in what can be done with the program. (I'm not talking about the state of the code base, but what I as user can do with Protux) I'm not doubting your capabilities and experience, but even with a great dev platform as eclipse, it will take a rather long time to port, if there is almost no time to develop..(?) Sure, time isn't an issue in OSS development. No deadlines etc. But at some point it would be rather nice to have something working at hand. I'm still happy to dedicate time and energy to the project. But I have to wait until you will finish what you've on your todo list (porting protux), before a new task can be "assigned" to me. "How things will evolve". It's just that I'm not able to tell if I still have interest/time/eneryg/etc to code on the project after porting is finished. I'm not writing code for "my users". I'm doing this to make a program I can use. To have fun. I do have a little problem expressing myself in the English language, but I hope you understand what I tried to make clear. Remon ___ Protux-devel mailing list Protux-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/protux-devel
Re: [Protux-devel] Possible Migration to Java
Hi all, 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 usingthem 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 therefavorites, 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 toless 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, thenit would consume less memory (no JVM required) and it seems the program wilrun 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 weallready 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, soeffectively 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) itappears 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, bothautomake 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 muchbetter 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, myquestion 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 theissue 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 p
Re: [Protux-devel] Possible Migration to Java
Hi all, It's been some time you heard something from me, but I'm still here :-) And I'm still working on Protux, though it has been very little due a hard disk crash, and no linux install for months, besides, I had vacation too ;-) Well, in regard to switching over to Java, the proposal came as a rather unpleasently surprise for me, since I don't have good experiences with Java. Apart from that, I've learned some more C++ and in combination with Qt3/4, it will IMHO serve Protux development as much as Java's does. Also, using other libraries is simpler (C or C++ ones) and faster then using them from within Java code, though it's possible. 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. 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. 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...) 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... 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. 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 memory efficient, and kdevelop as development platform is making huge strides to become on par with the Eclipse development platform feature wise... (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) 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. 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. 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... 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. Right now, I'm rather stuck on what to do, since I planned to work on Protux, also on porting it to Qt4, which I was doing at the time this proposal came in. So, I'm in favor of keeping Qt/C++ as development platform :-) Thanks for your time, Remon ___ Protux-devel mailing list Protux-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/protux-devel
Re: [Protux-devel] Possible Migration to Java
Hi Reinhard.. no it is good hear from YOU ! :-) very good indeed ! So my point, as you can see it to speed up development, which is my greatest problem. Few to no time free, nowadays... Indeed, there are some risks.I am making my own research on performance issues.. As soon as I get some conclusions I will post them. Regards On 9/2/05, Reinhard Amersberger <[EMAIL PROTECTED]> wrote: hi,at first, it's fine to hear some news from you, since the latest commitsare a long time ago ... ;-)about porting:I can't say much about that stuff since I'm not a coder, but many monthago I've checked out another java-audio-app called laoe www.oli4.ch/laoe/indeed ... it looks very nice, had a lot of functionallity, but wasdmnnn sloww compared to other applications.there is also another app I've heared about called Eisenkraut sourceforge.net/project/screenshots.php?group_id=132039which I did not tested so far.so if the other guys are willing to learn java ;-) , java will be right now fast enough to handle audio stuff and thehardware accelaration (I think this is done via pci card???) cost not tomuch I don't have a problem using java-protux.greetingsreinhard On Wed, 2005-08-31 at 13:04 -0300, Luciano Domenico Giordana wrote:> hello All !>> This is just to let you know that I have been considering port> protux/mustux to Java.> This is NOT a decision.This is just a intention "report". I´d like to> hear from the community and specially from the team.> My reasons are quite founded on several "perceptions". Some of them :> > - Java is a de-facto technology. QT isnt, yet.> - Productity in Java is hugely better than C++/QT, specially due> Eclipse> - Developing using CDT on eclipse/Kdevelop , when compared to> development java on eclipse, just suck. > - Java has a lot of ready-to-use classes that save us a lot of time.> That includes powerfull collections, Wrappers, Serialization stuff,> reflexion/instrospection, Garbage collecting, free/openm source > components, and so on> - Exception handling in Java is far better than C++´s. We can even> apply Responsability Oriented Programming concepts.> - Real clean coding is much easier in Java. No .h´s, prototypes, > makefiles... stuff like that..> - building is ridiculously simple in eclipse. actually you dont even> see it !> - Java performance has been compared to c++ performance. in some> cases, it is faster due very smart modern VM´s (such Java Tiger) > strategies, like native hot-compilation, hot syncing and binary> caching.> - ALSA can be (as far as it seems) used in Java using JNI> - XML parsing are a transparent , ready-to-use and robust technology > in Java> - So serialization is> - Documentation is also a strong point in java. Actually may doc> engines in c++/qt was inspired from javadoc.> - There a lot of java programmers out there, much more than QT > programmers. So the communities are stronger.> - GUI stuff can be made using visual editors, just like QT-designer.> actually. it is easier, cause no moc/meta-classes are needed.> - fast painting device for audio editing can be done with hardware > accelerated Java3D. other options can be considered.> - JMB seems to be perfectly implementable in Java.> - Deploy/distribution is very simple. We can even put a protux running> in the site as an applet for previous-testing. More users can be > attracted by that.> - Learnign curve for current developers is small. Actually, 1 month is> enough for a c++ programmer to learn java.>> there are more "perceptions". My intention is to show that we could > speed up the project by taking this radical move. Please, RFC as much> as you can.>> Thanks> --> Luciano Domenico Giordana> Software Engineer / Java/C++ Senior Developer > IBM do Brasil - 55 19 2132-7423 - [EMAIL PROTECTED] -> [EMAIL PROTECTED]> Project Protux : http://www.nongnu.org/protux> ___> Protux-devel mailing list> Protux-devel@nongnu.org> http://lists.nongnu.org/mailman/listinfo/protux-devel___Protux-devel mailing listProtux-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/protux-devel-- Luciano Domenico GiordanaSoftware Engineer / Java/C++ Senior Developer IBM do Brasil - 55 19 2132-7423Project Protux : http://www.nongnu.org/protux ___ Protux-devel mailing list Protux-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/protux-devel
Re: [Protux-devel] Possible Migration to Java
hi, at first, it's fine to hear some news from you, since the latest commits are a long time ago ... ;-) about porting: I can't say much about that stuff since I'm not a coder, but many month ago I've checked out another java-audio-app called laoe www.oli4.ch/laoe/ indeed ... it looks very nice, had a lot of functionallity, but was dmnnn sloww compared to other applications. there is also another app I've heared about called Eisenkraut sourceforge.net/project/screenshots.php?group_id=132039 which I did not tested so far. so if the other guys are willing to learn java ;-) , java will be right now fast enough to handle audio stuff and the hardware accelaration (I think this is done via pci card???) cost not to much I don't have a problem using java-protux. greetings reinhard On Wed, 2005-08-31 at 13:04 -0300, Luciano Domenico Giordana wrote: > hello All ! > > This is just to let you know that I have been considering port > protux/mustux to Java. > This is NOT a decision.This is just a intention "report". I´d like to > hear from the community and specially from the team. > My reasons are quite founded on several "perceptions". Some of them : > > - Java is a de-facto technology. QT isnt, yet. > - Productity in Java is hugely better than C++/QT, specially due > Eclipse > - Developing using CDT on eclipse/Kdevelop , when compared to > development java on eclipse, just suck. > - Java has a lot of ready-to-use classes that save us a lot of time. > That includes powerfull collections, Wrappers, Serialization stuff, > reflexion/instrospection, Garbage collecting, free/openm source > components, and so on > - Exception handling in Java is far better than C++´s. We can even > apply Responsability Oriented Programming concepts. > - Real clean coding is much easier in Java. No .h´s, prototypes, > makefiles... stuff like that.. > - building is ridiculously simple in eclipse. actually you dont even > see it ! > - Java performance has been compared to c++ performance. in some > cases, it is faster due very smart modern VM´s (such Java Tiger) > strategies, like native hot-compilation, hot syncing and binary > caching. > - ALSA can be (as far as it seems) used in Java using JNI > - XML parsing are a transparent , ready-to-use and robust technology > in Java > - So serialization is > - Documentation is also a strong point in java. Actually may doc > engines in c++/qt was inspired from javadoc. > - There a lot of java programmers out there, much more than QT > programmers. So the communities are stronger. > - GUI stuff can be made using visual editors, just like QT-designer. > actually. it is easier, cause no moc/meta-classes are needed. > - fast painting device for audio editing can be done with hardware > accelerated Java3D. other options can be considered. > - JMB seems to be perfectly implementable in Java. > - Deploy/distribution is very simple. We can even put a protux running > in the site as an applet for previous-testing. More users can be > attracted by that. > - Learnign curve for current developers is small. Actually, 1 month is > enough for a c++ programmer to learn java. > > there are more "perceptions". My intention is to show that we could > speed up the project by taking this radical move. Please, RFC as much > as you can. > > Thanks > > > > > -- > Luciano Domenico Giordana > Software Engineer / Java/C++ Senior Developer > IBM do Brasil - 55 19 2132-7423 - [EMAIL PROTECTED] - > [EMAIL PROTECTED] > Project Protux : http://www.nongnu.org/protux > ___ > Protux-devel mailing list > Protux-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/protux-devel ___ Protux-devel mailing list Protux-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/protux-devel
