 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / July 2007What's NetBeans written in?
I always thought NetBeans was a C++ app, but is it really Java? Why is NetBeans so much faster than Eclipse (in terms of UI responsiveness, compilation, etc)? We're having a heated internal debate about which IDE to use in-house. Up till now, we've used textpad+ant. Extensibility is one of our key reqs, but both IDEs fit the bill there. I appreciate any help, Thanks, -Vijay > Why is NetBeans so much faster than Eclipse (in terms of UI > responsiveness, compilation, etc)? Is it? I always shyed away from Netbeans because I had the impression that it was so terribly slow (on my slightly outdated iBook G4) ... granted, Eclipse also doesn't win a price on general responsiveness, but it at least feels a lot quicker than Netbeans on my machine. >> Why is NetBeans so much faster than Eclipse (in terms of UI >> responsiveness, compilation, etc)? [quoted text clipped - 3 lines] > granted, Eclipse also doesn't win a price on general responsiveness, > but it at least feels a lot quicker than Netbeans on my machine. NetBeans is written in Java. I find it horrendously slow (5.5 and 6.0M10). The original poster appears to be using an Intel Mac. AIUI, SWT has always sucked on Macs. I don't know if it is any better or worse on Intel vs PPC Macs. On Linux you might find Eclipse installed on an old barely functioning GNU "Java", which you'd expect to be slow. IIRC, the Eclipse compiler is often said to be faster than javac. AIUI, Eclipse will compile in the background, so you don't have to wait for ANT to chug away as you do on Eclipse. YMMV Tom Hawtin >> Why is NetBeans so much faster than Eclipse (in terms of UI >> responsiveness, compilation, etc)? [quoted text clipped - 3 lines] > granted, Eclipse also doesn't win a price on general responsiveness, > but it at least feels a lot quicker than Netbeans on my machine. Maybe NetBeans is just plain better written. I've always preferred it to Eclipse. There are more metrics than UI speed. The consistency and ease of use of the UI are arguably much more important. To my mind, NetBeans is much easier to use and has a richer feature set. It's much easier to deploy apps via NetBeans, for me, and to deploy and connect to app servers, databases and the like. By comparison I find the Eclipse UI much more recalcitrant and hard to navigate. Both IDEs tend to hide important aspects of the build, such as library inclusion, from the developer, but both export the needed libraries to the deployment artifacts. NetBeans also has that nice Matisse plugin for developing Swing apps. NetBeans also has better features for folding in the Struts or JSF frameworks and for SOAP Web services development. But lest we fall into the trap of fighting <http://en.wikipedia.org/wiki/Editor_wars> developers should be free to pick their own editors. They all emit text, and all feed the same project build process, so at the project-management level the differences vanish.  SignatureLew > I always thought NetBeans was a C++ app, but is it really Java? > [quoted text clipped - 6 lines] > Extensibility is one of our key reqs, but both IDEs fit the bill > there. Why not let each developer pick their own IDE? Why the dictatorial approach? Project builds should be done via Ant anyway, not through an IDE. All IDEs emit text in the end; if a developer prefers vi and they meet their deadlines and quality goals, more power to them. Don't shackle your developers. SignatureLew >> I always thought NetBeans was a C++ app, but is it really Java? >> [quoted text clipped - 9 lines] >Why not let each developer pick their own IDE? > Why the dictatorial approach? Because Java is a third generation language and a fairly primitive one at that. By dictating the IDE a company can obtain some of the advantages of a higher level language while retaining the underlying portability of Java. >Project builds should be done via Ant anyway, not through an IDE. All IDEs >emit text in the end; if a developer prefers vi and they meet their deadlines >and quality goals, more power to them. If another programmer changes my Matisse GUI using vi the text he emits will not include the text required for me to continue using Matisse. >>> I always thought NetBeans was a C++ app, but is it really Java? >>> [quoted text clipped - 12 lines] > advantages of a higher level language while retaining the underlying > portability of Java. By convention third generation languages are called high level languages. >> Project builds should be done via Ant anyway, not through an IDE. All IDEs >> emit text in the end; if a developer prefers vi and they meet their deadlines >> and quality goals, more power to them. > If another programmer changes my Matisse GUI using vi the text he > emits will not include the text required for me to continue using > Matisse. Is that vi's or Matisse's fault ? Arne Lew wrote: >>> Project builds should be done via Ant anyway, not through an IDE. >>> All IDEs emit text in the end; if a developer prefers vi and they >>> meet their deadlines and quality goals, more power to them. David Segall wrote: >> If another programmer changes my Matisse GUI using vi the text he >> emits will not include the text required for me to continue using >> Matisse. This is an argument against using a single IDE, not in favor of it. The trouble with standardizing on an IDE instead of just a platform and a language is that you get IDE depencies in your product, a Bad Thing. > Is that vi's or Matisse's fault ? Good question. It should be a matter of policy that no one can check code into the repository that breaks the build (compile step). It should be a matter of policy that no IDE dependencies exist in the code repository. The right way to build a Java program is from source, a pure text medium, using Ant. vi is certainly capable of emitting all the text needed for a successful build, in the hands of a competent developer. Ditto emacs, JBuilder, JEdit, NetBeans, Eclipse, OAD, WSAD, yada effing yada. Management needs to get it, and get off the developers' backs about such stupidity as mandating an IDE. SignatureLew >Lew wrote: >>>> Project builds should be done via Ant anyway, not through an IDE. [quoted text clipped - 9 lines] >trouble with standardizing on an IDE instead of just a platform and a language >is that you get IDE depencies in your product, a Bad Thing. Not really. If your IDE vanishes then, with a little effort, you can transfer your source code to punched cards and run it on any platform that supports Java and has appropriate hardware. Meanwhile you can enjoy the huge gains that a modern IDE provides. It only requires that the project team agree on some standard software. That software will range from source code control to 4GL development tools and an IDE is a convenient way of integrating them. Lew wrote: >>>> Project builds should be done via Ant anyway, not through an IDE. >>>> All IDEs emit text in the end; if a developer prefers vi and they >>>> meet their deadlines and quality goals, more power to them. >>> If another programmer changes my Matisse GUI using vi the text he >>> emits will not include the text required for me to continue using >>> Matisse. Lew wrote: >> This is an argument against using a single IDE, not in favor of it. The >> trouble with standardizing on an IDE instead of just a platform and a language >> is that you get IDE depencies in your product, a Bad Thing. > Not really. If your IDE vanishes then, with a little effort, you can It's that "little effort" that I seek to avoid by not forcing the build to depend on any given IDE. > transfer your source code to punched cards and run it on any platform > that supports Java and has appropriate hardware. Meanwhile you can > enjoy the huge gains that a modern IDE provides. Of course you can, and should, just not by dictating to the professional what tools will give them the most of those gains. > It only requires that the project team agree on some standard software. That software will Au contraire, it not only does not require that, but requiring one specific IDE could tend to mitigate the gains you get from IDEs. More effective is to require a certain performance goal, and leave it to the highly-trained professionals how best to achieve that goal. Mandating a particular IDE for software developers is like mandating a particular brand of hammer or other tool for your carpenters - you could do it, but there really is not a benefit and potentially some detriment. The best compromise is to insist that anyone /can/ build the project effectively using the standard IDE. So while I might hare off and use NetBeans to build my J2EE assignment (and will do so, given the choice), any team member can open it in the team's standard IDE, say Eclipse, and successfully build and test my code. The organization can also cluck and tell me that I'm on my own with NetBeans but they'll willingly support Eclipse. And fire me if I slip my deadlines. Thus, freedom with an inducement to stay with the team choice. > range from source code control to 4GL development tools and an IDE is > a convenient way of integrating them. I am with you on the benefits of IDEs. Use'em myself, ayep. SignatureLew > Not really. If your IDE vanishes then, with a little effort, you can > transfer your source code to punched cards and run it on any platform [quoted text clipped - 3 lines] > range from source code control to 4GL development tools and an IDE is > a convenient way of integrating them. Any modern IDE should NOT add non standard files that the project depends on (all other IDEs whether or not they call themselves modern or not are not modern). And has been said before in the thread: the build process should be totally IDE independant, for example Ant based (even though most modern IDEs can call any build program from within). The only two modern IDEs I have found and used are Eclipse (free) and IDEA (commercial) all I have tried others tend to try to make the user dependent on it. Both are good, but if you have the money I would recommend IDEA. And the crap about 3GL and 4GL belong to the 80:ies (maybe early 90:ies) A good IDE helps the developer and does not hide the details from him/her. just my 2 cents > David Segall wrote: >>> If another programmer changes my Matisse GUI using vi the text he [quoted text clipped - 3 lines] > It should be a matter of policy that no one can check code into the > repository that breaks the build (compile step). That is not what he is talking about. He is talking about the fact that manually editing code generated by a GUI builder will prevent other users from using the GUI builder in the future, because the GUI builder relies on certain comments and idioms. Arne David Segall wrote: >>>> If another programmer changes my Matisse GUI using vi the text he >>>> emits will not include the text required for me to continue using >>>> Matisse. > He is talking about the fact that manually editing code generated > by a GUI builder will prevent other users from using the GUI builder > in the future, because the GUI builder relies on certain comments > and idioms. I would call that an IDE dependency and consider the use of that GUI builder a risk. SignatureLew >Why not let each developer pick their own IDE? Why the dictatorial approach? You do need a common code beautifier so that you don't get false deltas on cvs checkin. Eclipse and IntelliJ can be made to look roughly the same, but not identical. What is needed is a beautifier plugin that works on all the major IDES and hooks itself up to automatically beautify before checkin. -- Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com > You do need a common code beautifier so that you don't get false > deltas on cvs checkin. Eclipse and IntelliJ can be made to look > roughly the same, but not identical. What is needed is a beautifier > plugin that works on all the major IDES and hooks itself up to > automatically beautify before checkin. What kind of nonsense is that? It's not as if the editor would reindent all the code upon loading a file -- if it does, throw it away faster than it starts up. >> You do need a common code beautifier so that you don't get false >> deltas on cvs checkin. Eclipse and IntelliJ can be made to look [quoted text clipped - 5 lines] >all the code upon loading a file -- if it does, throw it away faster >than it starts up. Let's say programmer A checks out the code and does some extensive work with in IntelliJ. Almost certainly he will hit Ctrl-Alt-R several times to make the code comprehensible. It will beautify to IntelliJ specs. Then he checks it in. Programmer B checks it out in Eclipse and does a simple modification. Hits the beautify button, which will beautify to Eclipse standards -- potentially changing every line in the program, changed or not. He then checks it in. Then programmer A checks it out again. And tries to figure out what Programmer B changed. CVS tells him every line in the program had a delta. If they both used a COMMON beautifier before checkin, CVS would report only REAL changes to code, not ones artifacts of differing styles of beautification. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Jul 14, 7:54 pm, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > If they both used a COMMON beautifier before checkin, CVS would report > only REAL changes to code, not ones artifacts of differing styles of > beautification. It sounds like CVS isn't very smart, and in particular doesn't know semantically-significant whitespace changes from semantically- insignificant ones. Perhaps this means they should choose a different version control product. SVN comes highly recommended with such features as: "The diff engine internal to Subversion can now ignore whitespace and eol-style when computing the diff." (since version 1.4; http://subversion.tigris.org/svn_1.4_releasenotes.html) > On Jul 14, 7:54 pm, Roedy Green <see_webs...@mindprod.com.invalid> > wrote: [quoted text clipped - 13 lines] > > (since version 1.4; http://subversion.tigris.org/svn_1.4_releasenotes.html) The cvs "diff" command, like the UNIX one it's based on, can ignore whitespace, too, and has had that ability for as long as I've used CVS (over seven years, now). SignatureLew >The cvs "diff" command, like the UNIX one it's based on, can ignore >whitespace, too, and has had that ability for as long as I've used CVS (over >seven years, now). However that won't help you if IntelliJ has done any of a number of transforms that are more that just whitespace, e.g. rearranger to reorder methods, converting concatenation to .append, renaming local variables... You need something quite clever to filter what changes you want to see. The low tech way to do it is to beautify code to the same standard on checkin. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > On Jul 14, 7:54 pm, Roedy Green <see_webs...@mindprod.com.invalid> > wrote: [quoted text clipped - 11 lines] > "The diff engine internal to Subversion can now ignore whitespace and > eol-style when computing the diff." That's common to many SCMs. It would have to be much cleverer to ignore changes in, say, brace style. And should it ignore the difference between if (i > 5) and if (i>5) Perhaps for Java (though probably not). Definitely not for a file intended to be read by humans. On Jul 14, 11:48 pm, "Mike Schilling" <mscottschill...@hotmail.com> wrote: > That's common to many SCMs. It would have to be much cleverer to ignore > changes in, say, brace style. And should it ignore the difference between [quoted text clipped - 7 lines] > Perhaps for Java (though probably not). Definitely not for a file intended > to be read by humans. Eh. Both of these: if (i > 5) { return foo; } and if (i>5) { return foo; } become if(i>5){return foo;} when semantically-insignificant whitespace is eliminated and semantically-significant whitespace (which would run keywords/ identifiers together or cause a // comment to run further if omitted) is reduced to single spaces (linefeeds in the case of terminating a // comment). (In this case the single space between "return" and "foo" remains.) You'll still get spurious deltas from changing if (i > 5) return foo; to any brace-using form of course. But simply reindenting everything with your preferred tab width or whatever shouldn't cause deltas with these options. > On Jul 14, 11:48 pm, "Mike Schilling" <mscottschill...@hotmail.com> > wrote: [quoted text clipped - 33 lines] > comment). (In this case the single space between "return" and "foo" > remains.) And who is to determine what "semantically significant" whitespace is? It's hardly the job of an SCM system. On Jul 15, 4:00 pm, "Mike Schilling" <mscottschill...@hotmail.com> wrote: > > On Jul 14, 11:48 pm, "Mike Schilling" <mscottschill...@hotmail.com> > > wrote: [quoted text clipped - 36 lines] > And who is to determine what "semantically significant" whitespace is? It's > hardly the job of an SCM system. Given that all the usual suspects (C, C++, and Java) treat whitespace pretty much the same, and source files for these are by far the vast majority of everything that ever gets checked into these repositories, it doesn't seem unreasonable for "C/C++/Java awareness" to be in such tools, certainly as a plugin or option. Basically, it can just recognize these files by extension (.c, .cc, .cpp, .h, .c+ +, .java ...) and ignore whitespace except between keywords/ identifiers (collapse to a single space), inside string literals (leave it alone), and the first linefeed after a // comment (collapse the contiguous whitespace there to just the linefeed). I'm also obviously not suggesting it genuinely modify the file in the manner described; just treat it as so modified for diff purposes. (This can of course be implemented using a temporary copy that really is modified that way.) Actually what I'd like to see is pluggable diff engines (binding to particular file types) so various language-aware diffs could be included. A smart diff engine for a specific language could do a lot more than ignore semantically-insignificant whitespace differences. For example, if it borrowed from eclipse a little a Java-specialized diff could tell whether two source files were semantically identical modulo bigger changes, like if (foo) { bar(); } vs. if (foo) bar(); and reordered imports. Plug this into a future super-SVN and it gets used to decide deltas on all .java files checked in. Presto: no more complaints about false deltas. As for the GUI builders, smarter parsing might be nice, so those can read any code that instantiates and invokes setup-type methods on Swing components and parse some sensible representation out of it. Alternatively, the GUI builder should generate an intermediate format that a standalone tool can convert to a Java source file; the intermediate format is treated as a project source file and the Java file as an object file. Much the way bison and yacc sources and output get treated by the C community. >"The diff engine internal to Subversion can now ignore whitespace and >eol-style when computing the diff." You also have false deltas of line breaks. I got in terrible trouble circa 1990 working in a company that gave the junior guys tiny, low-rest monitors and the old timers giant high-res ones. The old timers liked small fonts and very long lines. The new boys could not read such code and would introduce line breaks. This caused false deltas and territorial growling. You also have reflowing of Javadoc with Eclipse. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >>> You do need a common code beautifier so that you don't get false >>> deltas on cvs checkin. Eclipse and IntelliJ can be made to look [quoted text clipped - 22 lines] > only REAL changes to code, not ones artifacts of differing styles of > beautification. Now SUN has actually published a guide for Java style. Eclipse has this style as default. I would assume IntelliJ can also do that. If not then developers using InteliJ should not attempt to beautify the code. Arne On Jul 14, 8:21 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > Now SUN has actually published a guide for Java style. Linkie? >> Now SUN has actually published a guide for Java style. > > Linkie? http://java.sun.com/docs/codeconv/ Arne On Jul 14, 9:34 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > > On Jul 14, 8:21 pm, Arne Vajh?j <a...@vajhoej.dk> wrote: > >> Now SUN has actually published a guide for Java style. > > > Linkie? > > http://java.sun.com/docs/codeconv/ Thanks. Huh. To judge by the "code example", it's nearly identical to how I've always styled my code for decades, save two things: I put a space between method name and ( in method headers (but not method calls). When coding C++, I usually write short little methods all on one line, e.g. in an iterator of some sort I might write: inline my_iterator operator++ () { inner = inner->next; return this; } which is of course irrelevant to Java (and I rarely touch C++ these days anyway now that JVMs can run Java as fast as native code). (Obviously the above iterator would also have an operator bool to test for inner becoming null, and would blow up horribly if not tested for this. Equally obviously any Java equivalent I wrote would have hasNext() checking for the equivalent of inner->next == null and a next() throwing a suitable exception if already at the last element.) >>> Now SUN has actually published a guide for Java style. >> >> Linkie? > > http://java.sun.com/docs/codeconv/ "Now" being since 1999. SignatureLew >>>> Now SUN has actually published a guide for Java style. >>> [quoted text clipped - 3 lines] > > "Now" being since 1999. "Now" was not intended to be in a "at the present moment" sense. Arne >>>> You do need a common code beautifier so that you don't get false >>>> deltas on cvs checkin. Eclipse and IntelliJ can be made to look [quoted text clipped - 22 lines] > > Now SUN has actually published a guide for Java style. It's hardly exhaustive. Take imports as an example. Are wildcard imports allowed? If so, when should they be used? How should imports be ordered? Are blank lines allowed to separate groups of related imports? (In case anyone cares, my answers are "no", "alphabetically", and "maybe" respectively.) Beautifiers that make diferent decisions here will create spurious diffs that no SCM system will be able to eliminate. And one of my most common beautification commands is IntelliJ's "Optimize imports" which (with my settings) applies my rules. >I would assume IntelliJ can also do that. IntelliJ has pages of options to control your preferred format. Sun is nowhere near as picky. Then there is the standard ordering of declarations and methods. Then there are the IntelliJ strict naming conventions. They go further than I am prepared to go, though I am gradually bring my code up to compliance. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >> I always thought NetBeans was a C++ app, but is it really Java? >> [quoted text clipped - 15 lines] > > Don't shackle your developers. I agree. But a lot of team leads would sing the song about training, help, project files etc.etc.. Arne Lew wrote: >> Why not let each developer pick their own IDE? Why the dictatorial >> approach? [quoted text clipped - 4 lines] >> >> Don't shackle your developers. > I agree. > > But a lot of team leads would sing the song about training, > help, project files etc.etc.. Then the organization should fire that team lead and hire someone who knows what they're doing. SignatureLew > Lew wrote: >>> Why not let each developer pick their own IDE? Why the dictatorial [quoted text clipped - 13 lines] > Then the organization should fire that team lead and hire someone who > knows what they're doing. I would think it is in the 80%-95% of places where such rules exist ... Arne >Then the organization should fire that team lead and hire someone who knows >what they're doing. The smartest boss I ever had was also so meticulous he drove team members mad. Further he could not appreciate that everyone was not as brilliant as he was. He expected everyone to follow extremely intricate code as effortlessly as he did. Several times in my life I have had the exquisite pleasure to lead a team of highly competent people who did not fight with me, but who were not shy about pointing out my errors. It is the most incredible feeling to see finished code pouring out at a clip an order of magnitude faster than I could possibly do it myself, all done the way I would have had I the time and patience. Being the boss is such a pleasure, I can see why incompetent people love to try anyway. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > >Then the organization should fire that team lead and hire someone who knows > >what they're doing. [quoted text clipped - 13 lines] > Being the boss is such a pleasure, I can see why incompetent people > love to try anyway. But would an incompetent person get pleasure from something useful taking place faster than he/she could do it myself? and it's just cynicism to suppose that the appeal of managing is the opportunity to push people around? (Good story, though.) SignatureDecline To State (But the e-mail address in the header should work.) On Jul 14, 9:09 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote: > In article <3joi935kjen2uu9ajalq8kuqg3rp1jn...@4ax.com>, > [quoted text clipped - 10 lines] > cynicism to suppose that the appeal of managing is the opportunity > to push people around? It's different reasons for different managers. Good managers are probably like Roedy described. Managers whose real love is pushing people around are generally going to be bad managers. > On Jul 14, 9:09 pm, blm...@myrealbox.com <blm...@myrealbox.com> wrote: > > In article <3joi935kjen2uu9ajalq8kuqg3rp1jn...@4ax.com>, [quoted text clipped - 15 lines] > probably like Roedy described. Managers whose real love is pushing > people around are generally going to be bad managers. Yeah. I think I had should have some more caffeine before sending that post out into cyberspace -- "could do it myself" when I meant to write "could do it himself/herself" [1], not to mention that I didn't really get across the point I was trying to make, which had to do with the appeal of management to incompetent people. I think you're probably right [2], though -- "good manager" probably implies "motivated by what Roedy describes", while "motivated by a love of power" probably implies "bad manager". I doubt that the converse of either statement is invariably true, though. [1] Lew may want singular "they" here -- but neither "themselves" nor "themself" sounds quite right. Recast the sentence in the plural, I guess. [2] We agree on something?! Sort of a :-). SignatureDecline To State (But the e-mail address in the header should work.) > Yeah. I think I had should have some more caffeine before sending > that post out into cyberspace -- "could do it myself" when I meant > to write "could do it himself/herself" [1], not to mention that ... > [1] Lew may want singular "they" here -- but neither "themselves" > nor "themself" sounds quite right. Recast the sentence in the > plural, I guess. I'd use "themselves". Managers have split personalities anyway. One for their superiors, and one for their minions. SignatureLew >It's different reasons for different managers. Good managers are >probably like Roedy described. Managers whose real love is pushing >people around are generally going to be bad managers. When I have had things really click, there a virtuous circle. I am so happy with the people working for me helping me get so much done, that they work even harder to amaze me. I just beam with pleasure at them. Everybody takes joy in the productivity of the entire team and it acts like an oil to rapidly decide how to do a compromise. Then you start getting comments from them outside about the unusual productivity of the team, and get a real team spirit going. I remember one team guy I had who could never for the life of him have figured out WHAT to do, but once clearly directed, he could implement it so fast it seemed like a magic trick. Another of my angels was a guy I had to only explain the general principles of what I considered a good solution, then he would constantly come up with better ways to do things. With a team, you have a hodge podge of skill sets. Part of the game of being boss is giving people tasks they like and/or are good at. The error I see bosses often make is over-using seniority to decide who does what. It always helpful to look at problems from the boss's view point if you are an underling and from the underling's point of view if you are the boss. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Sun, 15 Jul 2007 00:01:39 GMT, Roedy Green <see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted someone who said : >The smartest boss I ever had was also so meticulous he drove team >members mad. Further he could not appreciate that everyone was not as >brilliant as he was. He expected everyone to follow extremely >intricate code as effortlessly as he did. The employee from hell was on a team I was not leading. We both figured it was time for some refactoring. The boss said no, we could not take the time just now. I accepted the boss's decision, given it was his money, he did understand our concerns and he had access to other considerations that I did not. However, the other guy went ballistic and wanted to stage a sort of coup. I refused to go along. He felt betrayed. He became furious with me for not supporting him and started phoning me and haranguing me on my every shortcoming. I eventually could not handle this and had to resign. It is quite a different skillset to play on a team and to develop by yourself and to be the boss. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com >I always thought NetBeans was a C++ app, but is it really Java? Definitely Java. It's open source; if you like, go to their website and download the source. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.