Slashdot Mirror

Eclipse is easily the best IDE i have ever used - especially for java compared to other bloatwares for development like
JBuilder/Netbeans/ Visual Age for Java. IMO, it is also the most easiest one to get familiar with. I have used IBM tools like Visual Age For java & Visual Age for CPP and boy, where they a pain to get started on.

This page has all the shortcuts in the IDE- valuable time savers :)

I'd like to take this opportunity to point you to IBM's SWT if you still think Java is slow as a client side app.

Just because Swing got into a politically driven quagmire, doesn't mean the language or runtime itself is hosed.

It's just a matter of your choice of libraries.

Like what? The only thing I can think of are NetBeans and OpenOffice, neither of which were released for the benefit of Linux. Is there something I'm missing?

ANyway, I agree with you. Here's to hoping for a total Eclipse of the Sun.

So why C# instead Java? Well if you're not concerned with being locked into a single platform (which has the lions share of the market locked up) you get all of the advantages of Java with quite a few extras thrown in.

Lion's share of what market? Last time I checked, most people were using neither .Net nor Java on their web/application servers, its more likely to be PHP or Perl. Tell me again why I should base my choice of platform on what other people are using.

Applications which look like Native Win32 apps. Sorry, Java looks like ass.

Java's awt toolkit uses NATIVE components for rendering. Java's swing toolkit is 100% skinable so if it looks like shit, talk to the developer of the app.

Applications that just seem faster. Sorry, Java just makes my new box feel like an 8088.

So I guess you don't bother with device drivers either. All that hardware abstraction just makes apps "feel" slower. Jitted Java is no slower than C++ if it is written properly.

A great set of development tools and a huge body of excellent documentation.

Isn't it crazy how there are no sources of information on Java. I guess C# has it all over Java on this one. I guess the FREE development environments like, eclipse or netbeans or jcreator or Sun ONE Studio just don't provide anything useful to a developer, except may a choice in their ide. You can always buy a Java IDE from Borland or Oracle, or a thousand other companies.

The ability to pre-compile applications, negating speed disadvantages of the JIT compiler.

gcj

Like I said, .Net is Java with the added drawback of locking you into a single platform.

To put it simply, a servlet container runs java objects that extend the abstract HttpServlet class. At the heart of it, the servlet container will provide you with a HttpRequest, containing the session and any objects stored in it, cookies, request headers, etc., and HttpResponse, which contains a PrintWriter that you can use to output whatever you want. Servlet containers also do things like user authentication and application management. There's quite a lot of configurable options for this stuff.

With J2EE being all the rage these days, there's a lot of inertia behind writing MVC web apps. Writing apps in JSP has nearly the same maintenance hassles as writing them in PHP. Instead of writing a JSP/PHP page that checks that a user is logged in and creates connections to a database, the idea is for JSP to deal with presentation and servlets and java beans to manage the database connections and "business" of the web application.

Some of the cooler (newish) tools that people are using with servlets are XDoclets and object relation persistence

So... take a look around. I strongly suggest checking out the Struts Framework. And this IDE's not bad. And this tool is pretty fun. I mean, I use it...

There is a lot of documentation built into eclipse. Look under Help -> Help Contents. There are developer guides and API references for most of elcipse/swt. Also, check Eclipse Articles on the eclipse website for some more tutorials and guides.

CPL also points out that there's no way for any contributor to guarantee that they're not unknowingly infringing on some third party's patent. IMHO, this sort of accidental patent infringement is the scariest part of patents and OSS.

The older IBM Public License had some onerous text that made the royalty-free patent license go away if you sued the contributor for infringing another patent, even one totally unrelated to the OSS project. I think this was intended to make "offensive" patent lawsuits unattractive, which was a nice goal. But the result was different -- some companies refused to use IPL'd projects because the license would have prevented them from suing IBM "defensively" if it intentionally infringed on some totally unrelated patent for hardware or whatever. I managed an open-source project at IBM for a while and we had a few potential users with this objection. After I left, the group managed to re-license the project under the X license. I'm glad IBM finally fixed this in the CPL.

Laura

IMHO, the problem with Swing is mostly that it is horribly overengineered and, frankly, that the implementation sucks. It's all in src.jar - read it and tell me if you would hire someone who would present that piece of crap as their prior experience.

chek out eclipse, it's a good example of java working on the desktop (although i wouldn't particularly advocate java for desktop apps, it's perfectly capable)

http://www.eclipse.org

You could always use SWT instead of Swing - it looks like it belongs on Windows (or it blends in with GTK, if you're under Linux).

Java has some very good IDEs, even compared to Visual Studio. Have a look at Eclipse and Netbeans for two good open source IDEs and IntelliJ for an excellent (and not that expensive) commercial IDE.

Nope,wrong site. Try Eclipse - it's VERY nice. Once you try refactoring, you'll like it better than VS.NET. It's written in Java but it doesn't feel like a typical slow Java app because it uses SWT, a fast widget toolkit that uses a 100% Java API with the widget implemented natively. It's CVS integration is top notch too.

What apps have you been using?

I used Borland's JBuilder 4 on Linux at my last job four years ago for all of my developement with fantastic results.
Most of the developers at my company use Eclipse for their development, a pure java IDE that beats the pants off of any other IDE I've used or seen. The only reason I don't use it is because of the lack of VI keybindings, I use good ol' Vim instead.

The point it moot anyway, Java really shines in the Enterprise side.

See the SWT project. It uses native graphics rendering and widgets in Java.

Oh, well w0000t! It's only cross-platform on Windows. What a very fucking useful piece of cross-platformness that must be. Truly its cross-platform powers are astonishing. What a dazzling range of platforms it crosses, indeed. If I ever need a cross-platform IDE, but I only want to run it on fucking Windows, Eclipse will be my first port of fucking call.

SWT also forces you to manually manage all resources. Yes people, it means that you once again are looking at huge potential resource leaks in your app.

I can only advise you to try out both IDEA and Eclipse to make up your own mind.

"the link you gave really backs up my point... everyone is saying C# is java and C++ done better."

I feel like I'm nitpicking at this point, but C# and .NET are tied together, as are most MS tools. You use one and you're tied into their whole system. I think the collective "C#/.NET" package is a competitor for Java on the detail level, not the conceptual (for as I understand it, the concepts are much the same); that was my entire point. Maybe I should have been clearer in that I mean the whole .NET/C# package.

---
"but what everyone seems to be looking for is a better programming environment, a COMPLETELY new environment; learning from all OO implementations and fixing the broken bits."

I agree; a language just isn't a language any more, it's the entire solution. This is Java/CORBA/what-have-you vs .NET/C#/etc.

---
"this can only be achieved by a new start, not a patching of an older one, or by making an alternative compiler/runtime download (think blackdown and IBM)."

If the change is so significant that the base needs to be heavily modified, yes, but I don't think that's the case. C#/.NET, AFACT, don't handle things much differently than Java/etc., they just add things in addition. Sure, some concepts would have to change, but Java's done that before.

---
"i think it is good that redhat want to up the support into GNU java projects, but i still think this will have little impact on the real executive world of programming, where OSS is still a scary prospect."

Well, first off, this will likely be LGPL or somesuch, as most development libraries are. I doubt that using this open form of Java will require programs to be OSS.

That said, I'd like to note that the company I working for is practically tripping over itself to use OSS as our foundation, primarily because it saves us an ungodly amount of time and money.

---
"Java does have one very good thing going for it at the moment however which i think is much more likely at keeping itself as top-dog: Swing, the GUI replacement for the heavily bloated AWT."

From here:
"Java AWT provides low-level widgets such as lists, text fields, and buttons, but no high-level widgets such as trees or rich text. AWT widgets are implemented directly with native widgets on all underlying window systems. Building a UI using AWT alone means programming to the least common denominator of all OS window systems."

There is more, but basically, AWT is the fast, quick and dirty widget toolkit. It's lightweight, it just isn't flexible at all. Bloat is not a word commonly associated with AWT.

Swing, on the other hand, is generally regarded as a slow piece of trash. ;) The default theme looks horrible and it's generally regarded as mind-numbingly slow (it's getting much faster). I wouldn't call Swing Sun's ace in the hole. Bloat and Swing are often synonymous.

---
"redhat are only going to finance coders to work on GNU/Linux and thats the point of the article. ... but redhat are not going to finance a *BSD port is my point."

Well, I'm speaking out of my arse here, and I'm too lazy to do quick research on this one, but I'd assume that BSD is already supported by most of the big-time OSS Java projects. Regardless, I doubt Red Hat would directly fund *BSD support, although they might not have a choice if they fund the GCJ developers.

---
"one thing is for sure though... we will see a lot more GNU java programs!"

I sincerely hope so. Either that or a new language that can take on MS, if it isn't too late (this thought scares me). Proprietary lock-in is something Microsoft has honed to a science. Their software is looking better by the year, but I can't say I'll ever really invest my time in MS: lock-in is too much of a turn-off and there are so many other good solutions.

That is correct. One of the core points of SWT is that it uses system widgets, which means that GUI resources (fonts, colors, windows, etc.) are all stored in OS memory. Most OSes out there don't have garbage collection, thus SWT does not. You could use finalize statements in the SWT implementation so that when an SWT Java object gets garbage collected the finalize code runs to clean things up, but there is no guarantee as to when the object will be collected -- thus threading problems and disposal ordering problems can occur, not to mention the trash that's left lying about the OS for an undetermined period of time.

This is all described in detail here.

The .NET Framework has a SLIGHTLY smaller footprint than the latest version of Java (46.5 vs 47.3 on my workstation). And it does more stuff -- a lot of the add-on packages for Java, including all of their J2EE crap, parellels what's already in the Framework. Not that it matters...including the framework on an install CD is trivial, and most Windows Update and XP users have it already.

You said it yourself. You can't really compare size like that since there is more to .NET than just the libraries and the VM. .NET uses a huge amount of bread&butter stuff in the Windows libraries, something which obviously can't be used by Java. At least not in the same way, since Java has to work on more than one platform.

.NET does NOT integrate the web into windows applications. .NET allows users to create web apps in much the same interface as standard windows forms, using a system called WebForms.

True, but it does integrate .NET into the web. It makes it very easy to build applications with much more "intelligence" on the client side, similar to building a XUL application using Mozilla.

The downside (or advantage, if you're Microsoft) is that you will only get these "rich" client experiences when running Explorer, preferably on Windows. But that's the whole point. Lock-in by pretending to be open, it's brilliant.

It also allows regular ASP pages to be compiled into faster versions a la JSP/Servlets.

True again, but they are still slower than JSP's on fast app servers, for example Orion. (disclaimer: I don't have the latest benchmarks so things may have changed).

What's cool about .NET is that the IDE supports all sorts of really useful data transformation and reporting mechanisms using SQL/XML/etc built right in...no rolling your own data access methods (though I end up doing it anyway).

These things has been available in Java IDE's/libraries/toolkits for longer than I care to remember. I believe it started with Sun's JavaBlend (which agreeably wasn't very good, but a lot has happened in the 6 or so years since it came out).

Today we have several frameworks, suitable for different needs. For example Hibernate, JDO, or, if you simply want a fast persistance layer: Prevayler. There are more, of course.

Also note that the the JDO specification allows different vedors to plug in different implementations so you're not relying on a single vendor. This goes for pretty much all of the J2EE specifications as well. I'll take that over Microsofts solutions any day.

.NET is better than Java for apps that will always be used on a Windows PC, because: - It has a much faster graphics interface, while maintaining a robust graphics toolkit.

And how do you know that your apps will always be used on a Windows PC? Do you have a magic crystal ball that can see into the future? Do you really want your apps to be limited to Windows only? Also, with the latest versions of Java, the speed difference (for well written applications, mind you) is neglible. Take a look at IDEA for a good example of a very efficient Swing application. And if you really believe you need native widgets, take a look at SWT, which Ecplise is built upon. But it's a pain to program in, and it's only really cross-platform on Windows. All other platforms suffer from the same problems as Swing apps do.

It has a better messaging mechanism (Events/Delegates are a GODSEND and are the sin

SWT is a viable alternative to Swing which is compiled natively. It's not official Sun, but it is open-source and part of the Eclipse project, which is backed by IBM, Borland, and others.

SWT Article

The Eclipse IDE is built on SWT, hence a different package for each OS.

SWT is a viable alternative to Swing which is compiled natively. It's not official Sun, but it is open-source and part of the Eclipse project, which is backed by IBM, Borland, and others.

SWT Article

The Eclipse IDE is built on SWT, hence a different package for each OS.

SWT has done much of that. It wouldn't be an extreme feat to conver the SWT API to line up with AWT, I don't think (but I don't know too much about either, so take a grain of salt...).

More links here.

Stuff and nonsense.

Java standardization occurs through the JCP. Regardless of this process, people are free to implement anything they want.

The fact that you chose Gnome bindings as an illustration of what is impossible would be very amusing to the SWT team at IBM who have already implemented them (as open source).

Sun retains rights to the Java trademark and associated frameworks such as J2SE and J2EE. You can't do a Microsoft and pass an incompatible version of these off as Java, but you can call it anything else you want.

Your discovery that there are Sun patents prohibiting fully compatible implementations will doubtless come as a bit of a shock to IBM, BEA and the several dozen other companies implementing fully-compatible platforms. I trust you've taken steps to inform them?

The penetrating observation that Java is a platform may well cause Linux C API fans some concern. Though not as much concern, I think, as the thought of having no high quality VM on the OS at all, thereby leaving it at a severe disadvantage compared to other mainstream OSes.

You might consider SWT. It's an open source Java widget toolkit (GUI API) that sits on top of native system widgets. I just started developing with it, so I can't speak for much, but it seems to be quite fast and is pretty easy to implement.

Some info:
The Eclipse project (of which SWT is a part of)
SWT Guide (good intro to SWT)
SWT API Specification
SWT Articles (many regarding topics internal to the API) -- scroll down to SWT

You might consider SWT. It's an open source Java widget toolkit (GUI API) that sits on top of native system widgets. I just started developing with it, so I can't speak for much, but it seems to be quite fast and is pretty easy to implement.

Some info:
The Eclipse project (of which SWT is a part of)
SWT Guide (good intro to SWT)
SWT API Specification
SWT Articles (many regarding topics internal to the API) -- scroll down to SWT

You might consider SWT. It's an open source Java widget toolkit (GUI API) that sits on top of native system widgets. I just started developing with it, so I can't speak for much, but it seems to be quite fast and is pretty easy to implement.

Some info:
The Eclipse project (of which SWT is a part of)
SWT Guide (good intro to SWT)
SWT API Specification
SWT Articles (many regarding topics internal to the API) -- scroll down to SWT

You might consider SWT. It's an open source Java widget toolkit (GUI API) that sits on top of native system widgets. I just started developing with it, so I can't speak for much, but it seems to be quite fast and is pretty easy to implement.

Some info:
The Eclipse project (of which SWT is a part of)
SWT Guide (good intro to SWT)
SWT API Specification
SWT Articles (many regarding topics internal to the API) -- scroll down to SWT

JDK 1.1 and more recently JDK1.2. VisualAge has it's own bastardized JVM (albeit with such nice features). VisualAge also does a better job of it than jdk1.4 (the JPDA), but the cost of the VAJ development team updating the JVM for each release was too much work. Hence, we have Eclipse. VAJ was nice in many ways, but I absolutely hated it for many reasons, all of which have been resolved with Eclipse. (pluggable JVM, decent CVS integration, using files in the file system, decent linux versions...)

mike

What's the difference between those and IntelliJ? Anything compellingly different? I've nearly decided to commit to eclipse, so if there's something better out there I want to know before I get settled!

Is IntelliJ free? (I saw something about a "trial key") Open source?

Don't take my word for it, download Eclipse and see for yourself.

Most developers (including myself) just don't have the time to get into the guts a program that needs a new feature, but a sensible plugin architecture allows a journeyman contributor to add a small feature without requiring a patch to the core. The Eclipse project is a great example of this, if Miranda (which I just found from the links on this thread) isn't enough for you.

1. Command line (if you like)
2. Free
3. Many Free IDE (i.e. Eclipse)
4. Available for Windows, Linux, Mac, Mainframe
5. Class files can be sent to friends without a recomple
6. Applications AND Applets
7. Tons of free learning stuff like Thinking in Java
8. No demented DLL hell and install issues that will f_ck up Dad's computer
9. Many specialized area of interest (i.e. Multimedia, 2/3d Graphics, Networking, Voice, Games, Web, etc.)

By sticking to Java the child will tend to learn clean programming design and algorithms, rather than wild pointer debugging tricks (also the case with BASIC I might add). As an added bonus the child will be learning one of the most commercially viable languages, and one with a lnog lifetime ahead of it IMO. I'd also begin exposure to SQL (MySQL or Postgres) when you felt the child was up to the added complexity and workload. Up to this point the cost has been $0.

Once the child (now 14 or 15 I'm sure;) was proficient coding in Java, I'd suggest exploring C, assembler, drivers and low-level machine architecture. Within a couple of years any CS program in the country should be easy pickings.

Where I'm working right now (TimeSys), I've been involved in contributions to Eclipse and Cygwin. Here's some advice:

ASSUME THAT YOU ARE NOT ALLOWED TO RELEASE ANYTHING WITHOUT PERMISSION.

If there's no clear policy already in place, ask. You probably don't have the authority to act as an agent of the company with regard to making decisions about IP. (If you don't know for sure whether you have that authority or not, you should assume not until someone tells you otherwise.) Keep pushing the suggestions/requests up the chain of command until you reach someone who has the authority to say "yea". They may still tell you "nay", but at least you'll be getting a decision on the matter instead of an "I can't make this decision, I don't want to bother my boss, so I'll just say no" response.

START WITH SOMETHING SMALL.

In my case, it was getting permission to submit patches to correct bugs - very small, very simple, very non-threatening things. The argument was that we could submit the patches, or go through the pain of developing the same patches again with each new release of the software we were using. That's a good way to get the foot in the door: show that there's a benefit to submitting patches that outweighs any perceived risk. If you can show that you spend X days out of every release cycle generating the same ol' patches again and again, it's an even more convincing argument.

DON'T PUSH TOO HARD.

For some companies, this is a big step to take. Let the folks who make the decisions think about the idea, answer their questions honestly, and be persistent without harassing them every day about the issue. You don't want to have them tell you "no" just so you'll quit bugging them.

BE HAPPY WITH WHAT YOU GET.

I don't mean that when you get the first "no", you should give up. You need to be reasonable in your expectations - IMHO, submitting patches for bug fixes is fairly minor, and the reaction to that request should give you an idea of how receptive your maangement might be towards the idea of more substantial work & contributions.

My employer lets us submit bug fix patches freely for one project, at the developer's discretion. Minor feature additions in the same project require approval, which is generally easy to get. Other projects require management approval for all patches, no matter waht. Some projects that require copyright assignments are still in the "we're considering it" phase, and may never be approved. We've contributed at least one large chunk of original code to a project, and are considering doing it for a couple of others, as well, because while we want the software to have feature X, we don't want to have to maintain feature X. That's a pretty good argument to try if you're trying to get approval to submit a patch that adds a feature or functionality to an existing project :-)

public String[] getStrings(){
String[] s = new String[vector.size()];
return vector.toArray(s);
}

public String[] getStrings(){
String[] s = new String[vector.size()];
return (String[])vector.toArray(s);
}

That is impossible. Java has to do the same as the C code, plus the extra overhead of doing the JIT. There is no way Java can be "as fast".

Ah, the "impossible" word. ;-)

You're presuming that the ahead-of-time compiler can "know" everything that the JITC can. That isn't true, in many common cases.

Another point regarding JITC compilation is that it can be for the exact target processor, something not typically the case for traditionally compiled programs.

All that said, current JVM performance certainly varies between 'better than C++' and 'worse than C++', with pathological cases in both directions.

The current 1.4 JVMs actually took a hit on some math operations, though that is supposed to be fixed in 1.5.

I hope gcj gets to the point where it supports the latest language spec. The libraries are tougher, and many of them aren't needed for interesting projects. For certain applications, an ahead-of-time compiler is nice.

By the way, for a good example of a 'fast' Java program, check out Eclipse from www.eclipse.org.

Eclipse found at www.eclipse.org. Does much of what you want. First class CVS integration, VSS integration. It has all kinds of plugins for editors. XML and JS for starters. It is primary a Java editor, but it very extensible. I consider it the new Emacs. It is also getting better all the time, with widespread developer support.

Eclipse found at www.eclipse.org. Does much of what you want. First class CVS integration, VSS integration. It has all kinds of plugins for editors. XML and JS for starters. It is primary a Java editor, but it very extensible. I consider it the new Emacs. It is also getting better all the time, with widespread developer support.

2) Java will always be slower than a native, non-interpreted language, even if you compile it into a binary.

Not true. First of all, Java is compiled, except it's compiled into byte-code instead of machine-code. This is unlike languages such as PHP and Perl, which must recompile the text source code into machine-code or byte-code each time it's run. While not as fast as machine-code in most cases, byte-code is definitely much faster than interpreted.

One advantage of byte-code to machine-code, in addition to portability, is that it can actually run faster in some cases. My friend did a project for his super-computing class in which he tested a simple algorithm written in both C++ and Java to see what would run faster. He used every level of gcc optimization, as well as a few JVM's. As expected, the compiled C++ version kicked the pants off of the Sun and Blackdown JVM's, but the IBM J9 JVM was around 50% faster than the C++ version. This speed advantage is due to the fact that IBM's JVM is able to optimize the code at runtime, while gcc must do all optimizations at compile-time.

Most people's misconceptions of Java are due to two factors: An incredibly shitty MS JVM and the horrid Swing GUI toolkit. When Sun wrote JWT and Swing, they tried to stick to the write-once, run-everywhere philosophy as much as possible. Unfortunately, the different OS's have very little in common when looking at GUI functions, so they basically had pixel capabilities to work with - no widgets. This means that the widgets are all done in Java instead of using libraries available from the host system. This is why most Java applications look nothing like the operating system they are running on, and run very slow. The SWT GUI toolkit, which is part of the Eclipse Project, uses the host system's libraries to render widgets wherever possible. This leads to an application that runs much faster and looks just like any other application for that operating system. Of course, they have to implement SWT for every host system they want to support, but it still runs on systems where support is incomplete/missing, albeit more like JWT/Swing.

Don't like Swing? Well you'd better like AWT.

bah, you should try eclipse

I would like to respond to some of konspire2b's claims about java.

From their FAQ:

java applications are difficult to install--- many users do not already have a copy of the java virtual machine installed on their machine. For these users, installing a java application means downloading and installing the java runtime, which is quite large and can be difficult to configure.

Java is extremely simple to install, particularly on popular OSes. Furthermore, no configuration is generally needed. Besides, you have java. So does your neighbor. Anyone who does not have java is, well, probably part of a group of fools trying to justify their failure to use the right tool by making weak claims that people don't have the tools to use it.

java applications start up slowly--- even the smallest java applications can take several seconds to start up, since the virtual machine needs to be loaded first.

This may be from some very outdated information. Early versions of java did have some speed issues, paricularly those using AWT. However, java VMs have made great improvements over the early days, and combined with improvements in hardware, it takes almost no time to start a java app. (There are still some third-party software pieces that may take a long time to start up, but that's the fault of the software's maker, not something inherent in java.)

java applications have slow, unresponsive user interfaces--- on slower machines, using java-based user interfaces can be frustrating (resizing the application window can mean taking a coffee break).

Any interface is the responsibility of its creator. As I said before, there were problems with AWT in earlier versions of java. However, great improvements have been made, and the claim that java applications have poor interfaces is groundless. If you don't believe me, try eclipse.

java applications use a lot of memory--- on most platforms, the virtual machine itself requires several MiB of memory, even for small applications that use very little memory. For more complicated applications, such as konspire2b, the virtual machine adds a lot of memory overhead. For example, kast currently uses about 1 MiB of memory when it's up and running. konspire 1.0 server (written using java) uses about 12 MiB. The interesting point is that konspire2b is far more complex that konspire 1.0 server (for example, the server portion of konspire 1.0 doesn't even have a user interface).

Modern VMs have a very small footprint, and in practical use, they do not add anything significant to the memory requirements of a program. The petty comparison here between kast and konspire is meaningless, as the two are completely different programs and there should be no expectation that they would be the same size. Memory optimization in java, as in any language, is the responsibility of the programmer.

java applications leak memory--- java uses garbage collection to manage memory, which seems to imply that programmers don't need to think about memory management at all. However, garbage collection gives a false sense of security, and java applications can still have memory leaks unless programmers are very careful. In fact, many java applications that run for extended periods of time leak memory to the point of exhausting all system memory. These types of leaks are very difficult for programmers to isolate. In fact, memory management may be more difficult with a garbage collector than without one.

I am a java programmer, and I can tell you first hand that it is very difficult to cause a memory leak in java. I have only ever seen two. One was due to third party software (and was not really a memory leak, but just a bug that caused memory not to be released in a timely manner) and the other was a poorly designed piece of code that was easily fixed. If you are using good design practices, you will never get a memory leak in java. Even wi

There is a c/c++ IDE option if needed, but its convoluted as hell!
from the faq:
"...you can import the glade toolkit bindings into Eclipse running on Mono using the open source IKVM Java virtual machine for .NET by Jeroen Frijters..."

love, peace, hope, dock

miguel

Also, Swing is a bloated pig.

SWT rules!

Just want to touch on two of your points. One, Vim does have autoword/autoline completetion. Second, Eclipse does have C/C++ development support.

''Unfortunatly its (sic) for java development''.

Not true. Eclipse itself is a development tool platform, it just happens that Java is the first and most widely know language. There's a C/C++ toolkit now, though, see the CDT. There's also an effort to develop a COBOL IDE!

but I really do use Java's platform independence all the time, and for non-GUI applications I think it works beautifully. The key here is the 'non-GUI' ...

For cross-platform GUI applications, try IBM's SWT and JFace. Eclipse uses SWT for its GUI and it works well for me on Windows XP, Mac OS X and Red Hat Linux 8.

Plus, modern IDEs like IntelliJ make it very easy to construct iterators and such

That's 16 lines of code for one property! This is tedious to write, and more importantly, very hard to read when you have many properties.

-- Jack

If you're looking for a Java Programmers IDE (i.e. not one that has a Swing/AWT dialog designer type thing), look at IDEA. It's worth every penny of the price. Eclipse is catching up to a lot of IDEA's features but doesn't stand a chance for a while to come.

Eclipse has the best CVS support I have seen so far. It helps resolving conflicts, figuring out which files to cvsignore, has great diffs, etc. Too bad that it has no support for good versioning systems (yet) ;-)

Generally, I find frames to be abhorrent, so I'm wouldn't be concerned, except that Eclipse uses frames.

Hopefully, this will cause the eclipse folks to re-think this piece of "architecture".

This is, of course, discounting the point that others have raised that browsers use frames. Web servers just serve up code that is not rendered in any particular format until a browser hits it.