Hi Wayne, thanks for sharing your experiences. I have some replies in line. I wrote quite a bit here, to kind of frame my experiences and where I come from. I'm not trying to say "mine is better than yours" or anything to create an argument, I hope.
On Aug 30, 2012, at 9:31 PM, Wayne Merricks <[email protected]> wrote: > OT for OSX as its almost turned into a bit of a Java discussion. Java has > its problems, the main one being write once test everywhere although it > generally works OK as long as you don't go over board with complicated > libraries you plug into. You normally just get stupid problems like fonts > wrapping because they are different sizes on different systems and the like. This is the primary reason why Java has layout managers and why you should use them. The layout manager mechanism asks the component for its preferred size, and organizes the horizontal and vertical layout to make things fit. > I'm not the worlds best Java expert by any stretch but over the last 5 years > of professionally using it, I've programmed a call handling system built on > top of asterisk that handled about 2,000 calls a day (at its peak) without > skipping a beat. I even have the complication of having to share data > between the UK and India but even that didn't break anything once I had a > MySQL slave over there. My data broker moves along at 100's of thousands of records per hour, sticking all of that into databases using Oracle JDBC, MS SQL server JDBC and postgresql JDBC interfaces. So, I am not worried about those tasks being possible/stable. > All I'm trying to say is like any language if you're a crap programmer you'll > make crap programs regardless of the language (I hope none of you have had > the misfortune of using the Cisco firewall management stuff, 1GB of RAM > minimum reqs for a firewall GUI in Java is ridiculous). In general the big > corp Java apps I've used seem to be overly complicated junk, thankfully I > don't have to use them anymore as I'm in a tiny IT shop these days. Most large scale Java development happens with all kinds of "productivity tools" which creates non-maintainable software systems, quickly. I've stayed away from that mode of operation to have maintainable software. > I'd be all for converting to Java as I can write it while I sleep instead of > having to think about all this C stuff but I think I'm leaning towards the > fact that its a lot of work with not a great pay off. I don't know a lot > about QT but I know that QT5 is going web orientated and QT is quite cross > platform once you set it up so it seems like the Java cross platform > advantages will disappear. The issue for me, is that GUI layout and productivity using an application that requires a GUI should be something that you don't worry about. The issues I have with my casual exposure to the QT code in Rivendell, is that I don't really know QT, and I stopped programming in C (I worked for AT&T on the 5ESS project in the 90's and did thousands of lines of it back then) since about 1998. I just have tried hard to not be burdened by memory management and C portability with "configure". Finding enough Java work to not have to do that, has been easy. But, I've been doing Objective-C stuff lately, and so I'm back in the position of dealing with less features in the language. > Finally I need to quickly defend Eclipse (Netbeans is OK but I found the auto > generated GUI code it produces to be a complete mess and it put me off using > the whole thing), I haven't found any IDE that comes close to it once you get > used to it, with the tool tip API lookups, auto completion and an awesome > debugger its pretty much Visual Studio but free (albeit without a gui > builder, which suits me). Auto generated GUI code is not my thing either. I've always hand coded my GUIs and I've found that easy to do using my Packer class that I describe below. > Its a rude awakening going from that to gedit for C++/QT stuff where the only > way I know of debugging is to throw in lots of console writes and keep > compiling until the errors go away (I have the same problems with PHP so its > not just a C/QT thing). I really don't want to start going on and on about Java vs QT, because I don't have the background to really compare them. In 1997, I was coming out of a TCL/TK project at AT&T where I had been using the "pack" command to build GUIs and as I was picking up my speed on Java GUIs, I really wanted to have a rectangular layout manager that was easy to use, like the TCL/TK packer was. The GridbagLayoutManager, in Java, has the same features as "pack", but it's API was designed like a Windows 3.x API with about 10 lines of assignments needed per component, and that's what I see in the QT code for GUIs as well. My experience with that was that there were always issues with trying to reuse code because so much stuff was "invisible" for all the lines of code. So, I wrapped the GridbagLayoutManager with a new API by subclassing it. The resulting class and interface is at http://java.net/projects/packer. Basically, for a simple "Label: " [text field] "Label: " [text field] "Label: " [text field] "Label: " [text field] kind of rectangular form, you'd code it using my Packer class with something like int y = -1; // how this value is used and changed is key to easy layout JPanel p = new JPanel(); Packer pk = new Packer( p ); // move to next line and put two fields on it for( int i = 1; i <= 4; ++i ) { pk.pack( new JLabel( "Field "+i+":" ) ).gridx( 0 ).gridy( ++y ).inset( 0, 4, 0, 4 ). pk.pack( new JTextField( 10 ) ).gridx( 1 ).gridy( y ).fillx().inset( 0, 0, 0, 4 ); } The Packer class instance wraps all of the context inside of itself, so that there isn't a "sharing" of state across blocks of code like there is, when a "structure" is reused over and over with variations on its content. The deal for me, is that layout is then compartmentalized in a way that you can move fields around, wrap groups of things into panels and move panels around etc. This could be done with a C++ class as well, for QT I suppose. With Java LayoutManagers, then you also get nice cross platform layout support so that any font size works depending on your screen size. That means you can use large fonts on large screens with excellent readability. Gregg > Regards, > > Wayne > > > -----Original Message----- > From: [email protected] on behalf of Gregg > Wonderly > Sent: Fri 31/08/2012 01:53 > To: User discussion about the Rivendell Radio Automation System > Subject: Re: [RDD] OSX > > > On Aug 30, 2012, at 6:05 PM, Fred Gleason <[email protected]> wrote: > >> On Aug 30, 2012, at 18:11 08, Dan Mills wrote: >> >>> I don't know if it is just me (And I have not worked on Riv for a >>> while), but EVERY major java application (Possibly except Chrome, I have >>> not used it much) I have ever run across has been a right pain to >>> install, xml infested, massive, slow to start up, and generally slightly >>> crash happy, maybe it just comes with the "Enterprise" label or >>> something..... >> >> This has been my experience as well, with the addition of extreme >> sensitivity to the precise version of JRE being used, to the point where >> I've even had to *downgrade* it to get a working setup. Not a particularly >> impressive showing for a system that purports to deliver 'write once, run >> anywhere' functionality. This was several years ago however, so perhaps >> things have improved since then. > > Many people seem to have experience with JavaEE servers as their "Java" > experience. There, too many large scale, mismanaged resources and > "code-by-tools" creates a lot of problems. > > I've been using JavaSE for a data brokering system that I wrote from scratch, > deployed in the petroleum products market, for the past decade. My > experience has been that I haven't had to worry about Java versions, except > for some point releases with actual bugs. > > I understand the GC at the wrong moment won't be good. That's why I'd prefer > to leave the play out system in a native C/C++ application framework. It > could still load the JVM in that process, and call out to it, if that was a > useful part of the system. GC in that JVM would happen on threads > independent of the play out mechanisms. > >> >>> I mean eclipse, really, come back emacs (or vim) all is forgiven, and a >>> glorified text editor really should not crash! >> >> I'm there, baby! Using emacs v23.1 (and yes, it's available for OS X as >> well). :) > > I'm a VI user and I am not always excited about IDEs. The Netbeans IDE, is > much preferable to Eclipse for me, because it seems to be more like an editor > with a navigation tree, instead of some kinds of systems engineering > nightmare. > >>> Now as it happens the log playback logic is somewhat too tightly tied to >>> the gui in rivendell, and could very usefully be abstracted into a >>> logplayd process (Or three), but remember that even this is fairly hard >>> realtime if you want the transitions to sound smooth. GC at the wrong >>> time there would be a dead air situation, possibly making the next >>> transition also miss its timing. >> >> This is the real crux of the matter, I think. Multimedia systems that >> demand realtime performance remain the almost exclusive province of C/C++. >> Unpredictable GC in languages with automatic memory management is one of the >> major reasons for that. > > As I said above. I'd prefer to leave the play out system outside of the > realm of a Java implementation. That would not be a great thing without some > careful engineering. > > Don't get excited or too argumentative, because I'm just thinking out loud > here. > > Gregg > >> Cheers! >> >> >> |-------------------------------------------------------------------------| >> | Frederick F. Gleason, Jr. | Chief Developer | >> | | Paravel Systems | >> |-------------------------------------------------------------------------| >> | The UNIX philosophy basically involves giving you enough rope to hang | >> | yourself. And then a couple of feet more, just to be sure. | >> | -- Anonymous | >> |-------------------------------------------------------------------------| >> >> _______________________________________________ >> Rivendell-dev mailing list >> [email protected] >> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev > > label or > > ####################### > Scanned by MailMarshal > ####################### > > ############ > > Attention: > > The information contained in this message is confidential and intended > for the addressee(s) only. If you have received this message in error > or there are any problems, please notify the originator immediately. > The unauthorised use, disclosure, copying or alteration of this message > is strictly forbidden. Christian Vision or any of its subsidiaries will > not be liable for direct, special, indirect or consequential damages > arising from alteration of the contents of this message by a third party > or as a result of any virus being passed on. Please note that we reserve > the right to monitor and read any e-mails sent or received by the > company under the Telecommunications (Lawful Business Practice) > (Interception of Communications) Regulation 2000. Christian Vision is > registered in England as a limited company 2842414 and as a charity > 1031031 > > ############ > <winmail.dat>_______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
