Slashdot Mirror

Eclipse (also free and currently my IDE of choice) has more and more of these kinds of features built-in with each release.

It's still mostly cleanup stuff, but it looks like they're moving towards having more of this stuff included by default. Currently you can set the error level (ignore, warning, error) when you do a build for unused imports/parameters/classes/methods/fields, circular dependancies, unreachable code, methods with constructor names, overridden methods that aren't package visible, hidden catch blocks, non-static access to static variables, using a char array in String concatenation, etc..

Checks on general threading practices and lock sequences would be cool... that seems to be a dangerous area for new Java programmers. Ever seen a servlet with doGet() and doPost() synchronized? No, it didn't scale very well.

You wanna get your hands on a copy of Eclipse for Java, mate. Better yet would be Borland JBuilder Enterprise edition, but that costs $$$.

Daniel

I personally like CVS very much. But I think that I am going to like Subversion
Subversion
even more, in a few versions time. If you can wait a bit more than that you might want to look at an IBM research project called Stellation Version Control
Stellation

CVS is quite nicely integrated in that super IDE, Eclipse. And the two others have integration underway.

It might take some work, but Eclipse from IBM has improved a great deal towards becoming a good environment for project management. Its geared towards projects written in Java, but there is a C/C++ Perspective plugin if you prefer...

Its a good platform for managing a collection of custom ant build scripts if you decide to go that direction (assuming your in java of course...)

If you'd prefer something more specialized, the plugin architecture isn't bad and could save some time with interface work. Especially since any windows from other perspectives that you like can be dropped directly into your custom-built perspective.

Food for thought...

www.eclipse.org

Didn't anyone in IBM management notice that Java does not have good GUI support?

I don't think that's an issue. This is supposed to be a J2EE office suite. I've never seen it before, but I'd imagine that the GUI is created using web-based technologies like HTML, CSS and Javascript. Not that that's any better though. :)

Although, for what it's worth, Java GUIs can actually be quite good if SWT is used.

I wonder if this suite is built with IBM's SWT toolkit, a quick, ultra-slick alternative to Sun's Swing.

You can get Rendezvous for Java from StrangeBerry. I'd like to see this built into Eclipse.

Good idea.

Apache has always been the leading web server - IIS was released by MS as a knee jerk reaction to it's dominance (which is probably why it's like Swiss cheese).

Perhaps he really meant PHP Overtaking ASP which is the first Open Source project I know of to come from behind.

Also interesting to watch is whether Eclipse eclipse Visual Studi...

Linked right of the main page (termed "what's new"): http://download2.eclipse.org/downloads/drops/R-2.1 -200303272130/whats-new.html.

And what exactly is the benefit of having interoperability with the stock Java ORB in GNOME?

You never know... May it be pulling Bonobo components from Eclipse plugins?

From the Eclipse 2.2 Draft Plan:

Allow editors to open files outside workspace. A common request is to be able to open a file that is not part of the workspace using Eclipse. In addition, applications would like to provide file extension associations so that double-clicking on a file in the OS desktop would open the associated Eclipse editor. The operations and capabilities available on these "outside of the workspace" files would need to be defined. [Platform UI]

You're missing the point. So Eclipse doesn't provide a Tomcat plugin; big deal. A number of other developers provide plugins to do almost anything you might want, most of them open source (though there are some commercial plugins.) Have a look at the SysDeo Tomcat Plugin before you pass judgement on Eclipse.

My only gripe with Eclipse plugins is that Eclipse doesn't have a central repository that uses their automatic install/update mechanism for plugins to save people from having to hunt for the plugins. Instead they've let the community pick up the slack -- so you sometimes have to hunt around looking for just the right plugin.

I haven't used Idea yet though I don't think they will be able to keep up with free and open source.

The new features planned for version 2.2 will surely blow them out of the water.

I think IBM have done a fantastic job to date and I hope it keeps up.

I've been using eclipse since 2.0, and have been closely following its development - at first out of curiosity (when I discovered Erich Gamma of the Design Patterns fame was on the project), but have over time learnt a great deal from their articles and best practices...

• They probably have the best document about evolving Java APIs, i.e. maintaining backwards compatibility.
• Meeting deadlines. When they publish a game plan, they stick to it - very rarely missing their milestones. They've long adopted continuous integration (automated builds, unit tests), and frequent releases.
• SWT - their cross platform widget set, which has ports for most windowing systems under the sun. Its a lot faster and looks better than Swing. Its really a very thin JNI layer (C to Java interface) on top of the native APIs, so if you've programmed in GTK, you could take a look at the wrappers and figure out pretty quickly how to use SWT. It does have problems if there are humongous amounts of calls to be made (like with large tables - in which case you can just use Swing).

Anyway, one of my favourite features is its scrapbook that lets you execute Java statements on the fly like an interpreted language.

Worth a try if you haven't experienced it. I should know... there's an unused paid JBuilder license still sitting in my drawer.

I tried Eclipse a month ago, and was severly disappointed. First off, I had to read the tutorial to figure out how to build HelloWorld with their system. Not intuitive. Also, the SWT library is a complete joke -- it doesn't look like the host OS, and requires native code. No java program using SWT is cross-platform, so what's the point?

Are we using two different Eclipses? From unzipping the binary distribution to setting a couple preferences to a System.out.println("Hello world"): 2 min.
Also, how can SWT not look like the native OS when it's a JNI wrapper around native widgets? Furthermore, to write SWT apps no native code has to be written by the developer, you simply need to include the SWT native library in your java.library.path. SWT is cross platform! The widget classes are nicely abstracted so that each implementation of the JNI library for each platform requires no code changes on your part. Please learn more [SWT FAQ] before dismissing it wholesale based on incomplete information!

Seems plausible.

I saw nary a Sun logo on the eclipse.org page of consortium members.

With IBM, HP(Compaq) and several other *nix vendors - as well a several application vendors that drive Sun harware sales - in the consortium, you'd figure they'd be in from the get-go.

IMHO, this just goes to show that Sun doesn't truly get what OSS is yet (Open Office being the exception to the rule), and what it could do for them. If they would release Java as a true open standard, they'd end up looking like the proverbial cat in the bird cage.

Soko

That's all I can say... they've certainly packed an awful lot into this release. The JDT team, in particular, seems to be consistent about picking up some of the best features of other IDEs and editors and incorporating them into Eclipse.

If you do Java development, I'd recommend giving Eclipse a try. I've been using it for about a year now, to do plugin developent for Eclipse itself, and I'm still finding out new tricks and shortcuts to make my life easier.

If you do C/C++ development, check out the CDT project. While the current incarnation (1.0.1) of CDT is definitely usable, there's a lot of work going on to expand the capabilities of the C/C++ support and bring it up to par with the Java development tools - adding in things like incremental compilation, source navigation/browsing, refactoring, and all the other IDE goodies that Java devlopers already enjoy.

Plus - there's over 250 plugins available for Eclipse, including things like an RSS channel monitor for slashdot in your IDE.

I spend most of my days working on software that is written exclusively in Java (OK, *some* C++ for native utilities, called through JNI) and our client component is blazingly fast *and* runs with almost no modification on all major (and a few minor) platforms.

Oh, did I mention we use SWT?

I was kind of shocked to see an Eclipse project intended to support COBOL. Check it out here. I wonder if this would be the first ever COBOL IDE.

Inheriting everything from "Object" isn't good enough either... which is why Java 1.5 will have templates as well.

Often times you want the compiler to be able to do some type checking at compile time to make sure you can even call certain functions on certain objects.

OOP is ok... but it can't solve all problems easily and refactoring of old OOP designs is a huge pain in the ass sometimes. This is why there are technologies like Aspect Oriented Programming in existence. AspectJ is a good example of this and I believe it is available with the popular eclipse IDE.

Oh, I completly agree with you catch23. Their use of dynamic-proxy is not real AOP (like with AspectJ), in the sense they don't really use Aspects.
Anyway, my point was that their design was completely different from Sun's : I was wondering what they could have copied from Sun, as JBoss was accused of copy/pasting code from Sun. I mean, even if they don't do bona fide AOP, they still do things completly differently from Sun.

You raise some really interesting points. I don't agree concerning the performance problems : my JBoss servers are running blazingly fast (BTW, I use BEA's JRockit JVM, on Linux). In practice, I always had excellent performance with JBoss. Besides, it's extremely easy to make a cluster/farm of JBoss servers, and I rely on that in case of scalability issues.
I've heard of BCEL yet, but not of Javassist - thanx for the link, I'll have a look at it.

Julien Dubois.

This is about tools, not languages.

Tools should make your life easier, not harder. Unfortunately, many Java IDEs fail to take this concept quite far enough.

I've used NetBeans for several years, but having finished a few weeks of C# work, I am now missing the IDEs code folding.

Yes, I know that's available in JEdit.

In fact, that's part of the problem. Anything feature you could possibly want from a Java IDE is out there. Some in NetBeans, some in Eclipse, some in JEdit, some in Idea, (the list goes on) but not all of them in one place.

-- Aumaden

Yes, but eclipse is quite the amazing beast, also!!!

I read about it about a year ago in Java Pro.

Here's an article

And here
And here

Hope that helps.

Aspect Oriented programming is a brand new programming paradign, kinda of like the switch you made when going from functional programming to object oriented programming. It's a different way of expressing your programs

The reason that Aspect Oriented Programming was created was due to "cross-cutting" concerns that cannot be easily modelled in object oriented programming. I read the presentation for AspectJ and the example they used was logging in Apache Tomcat. Bascially the code that is used for logging is scattered throughout the whole program on hundreads of different lines, not all in one nice neat class. Aspect Oriented Programming wants to give the programmer the tools to gather all of this code together.

Bascially, Aspect Oriented Programming is supposed to result in: less tangled code (code that is fragmented throughout your program because you are unable to modularize it well), more natural code, shorter code, easier to maintain and evolve, and more reusability.

One question I had about the book that the review didn't seem to answer was did the book talk at all about designing using Aspect Oriented Programming? Just like Object Oriented Programming, it's a great tool until you get some inexperienced programmer who just knows how to program functionally, and thus doesn't use the advantages of aspect oriented programming. I too would like to learn more about how to go about designing a program in an Aspect Oriented way; such as how to identify aspects, what are some common aspects, etc.

In all, I'm very excited about Aspect Oriented programming. I think it has the ability to allow programming to shape thier programs more naturally, make their programs easier to understand, and make the whole process much eaiser. But of course as with any new technology, it has some growth and refinement to go through yet.

Those of you who would like more information can check out the AspectJ webpage, or the Aspect Oriented Software Design webpage.

That's a pretty cool idea. Why don't you check out the Eclipse IDE, and see about writting the plugin or offering the suggestion. They already have CVS support, so I'm sure a proof-of-concept would only take a few weeks to get banged out.

http://www.eclipse.org/

dr. u

It's not just a coincidence that my Java work is done with either Eclipse or Jikes on the command line....

I don't see why it's impossible to get the L&F things right on the line under Windows like Apple did in OS X...

Apple provides real native L&F for Swing-Apps running on OS X. (By backing it with native Cocoa bindings) This should be possible under Windows too.

Besides all, I'm still rather confused about the role SWT is going to play and I'm really interested on that issue... (because SWT looks promissing to me)

Here is the correct link to Eclipse.org

Swing (Sun's tech that lets you create GUIs the same xplat) stinks. But even Sun admits it, and (see the same link) they are doing something about it. Swing is no longer "a way for database apps to display debugging information in X11".

I'm still hoping for a Swing replacement from Sun that'll ship with its java virtual machines, but until then we have IBM's SWT which ties the widgets much more closely to native counterparts and Apple's attempts to merge Swing directly to native GUI widgets. We're nowhere close to Windows.Forms yet, but Swing's not so bad that you can't get the hang [notice I didn't say Swing] of things quickly.

The point being that you have options. Once you get the hang of Window Managers (doesn't take long) and creating some sort of Model for everything (from sorting tables to adding new values to lists), you can do complicated layouts that work xplat more quickly in the text editor of your choice than you could hack up a static UI (ie, that doesn't resize well) in the Visual Basic IDE -- which, as everyone knows, is really what makes VB GUIs "so easy".

(Aside: Even more importantly would be a standards-compliant parallel to what Microsoft's Web Forms does for IE... a quick, smart widget toolkit for the web. A "JWeb Forms" for JSP would do a lot to enable smart web-enabled UIs to Java web services.)

And there's nothing about Java that stops it from being a great client-side language short of Swing. Moore's Law and clever JIT VMs have pretty much done away with any show-stopping speed issues. Another hurdle is the fact that Java only compiles to bytecodes, making [even commercial] apps trivial to decompile, but if you look at VB 7 (aka, VB.NET) and C#, Java's most closely related competitors, they've got the same problems.

And sure, Java is more "Write once, test everywhere" than "... run everywhere", but you're not going to find an easier port from one platform to the next than Java. It commoditzes the user's operating system, and that's a great thing.

And heck, I'm using it. At least I'm putting my money where the keyboard is.

The short answer to your question is yes, you can really do in java whatever you might otherwise want to do with vb/vc. Most people's complaints at this point are unfounded, and usually based upon unfamiliarity with the latests versions of java, and the vast sea of tools that are available to make java development easy.

The long answer is yes, if you can choose to not support retardedly old jvm implementations. If you are going to try and support microsoft's jvm, then you are going to have a hell of time getting things to work well. I've found that if you support 1.3+ you are usually ok. What would be even better is if you were able to control the jvm under which your application runs, ie bundle the jvm with your application, and use it. That in general would save 99.9% of those types of headaches.

As far as examples of applications that are fairly large scale, and are implemented in java, you might want to look at Intellij's IDEA, or Eclipse. Yes I know that both of those are IDE's, but they are fairly large in scale, and have a fairly sophisticated windowing env.

I think Java can't die that easily. Nearly all posts forget about a very big supporter of Java, IBM. IBM will never support Microsoft-propietary on its servers. (I mean, since IBM started eclipse, it's entire development platform is built and made for Java.

So with server suppliers Sun and IBM it's natural to use Java on the server. An when the backbone is Java, why not use the same environment (Java, JDBC-Drivers, XML-Access) on the client. (it's by far easier to maintain...)

But of course: It'd be great to spread JVM among the clients around the world, although JVM is a fairly "heavy" thing over the slow lines out there... (at least Sun's, which is the only "comfortable" under Windoze)

So the developing community should concentrate on making standard routines for installing the JVM by providing direct links on webpages and so on. (like this happened with Acrobat Reader which you can expect being installed on nearly every system connected to the internet)

If you play with Java, have a look at Eclipse (www.eclipse.org) It can parse the Java code as you write and flag errors with a colored squiggle underline much like MS Word's grammar checker. On top of that, in the margin it offers a "quick fix" icon. Click it and it shows you a couple of ways that it can automatically correct it. (e.g. If it doesn't know about that class in one context, but there's a package with a class by that name over there it can automatically add an appropriate import.) It's a pleasure to use for writing Java.

One of my "favourite" bugs is a simple accessor:

public Integer theVal;

public void setTheVal(Integer theval) {

this.theVal = theVal;

}

Which, of course, is legal java but does nothing when the accessor is called, and can be difficult to find that the parameter is incorrect case.

Eclipse warns you if you have just made this mistake. Man, I love that IDE!

And I think there is a c++ plug in for it.

Java programs aren't cross-platform. Otherwise I could download a single package to run on whatever OS I have.

Java is a platform, or at least Sun calls it that. Following that reasoning leads to absurdities like claiming Super Mario Brothers or StarCraft are cross-platform, since they work in emulators. You could say I'm being pedantic, that "running on a platform on platform A" is practically equivalent to "running on platform A", but that's not so.

To the point, suggesting the use of Swing imposes serious limitations on the project- mainly that it has to be written in Java and run on a JVM. The performance penalties are appreciable. (It is possible to use Swing to display a non-Java program, but ugly and impractical).

The other GUI toolkits that got good recommendations generally have multiple language bindings for them

PersonalJava is sold on devices with 64 megabytes of RAM, or even more.

With such a control over the hardware, you are allowed to bypass the XWindows system, which kills the performance in such desktop environments as KDE and Gnome. Painting directly to the hardware buffer, buttons and other widgets can be responsive in a unique way.

The only common manner across all major platforms, BSD, Linux, yes, even windows that you can do this is via DirectX. Compiled binaries can be ported cross platform due to the quality of the cross platform implementations.

Not only this, but the breadth of the system allows realtime multimedia eventing systems, such as audio responses to important system events. Platforms such as NT incur an inherent delay, but not when using directX.

The problem is that it's only available for Windows and Linux, and since the underlying code is native, it has to be separately developed and maintained. Since more GUI apps are run on Windows, there's more pressure to make the Windows code work right, and the Linux code is always a little behind.

Are you nuts ? SWT/eclipse is available for 7 platforms (you read it right!) which include Windows, Linux (RH and Suse), QNX, Solaris, AIX, HP-UX, and MacOSX.

I am using it right now for my development work and so far is has been a lovely experience. The widgets are native and SWT really rocks. In comparison, Swing looks like a tonne of lead tied to Java's foot. Once running you cannot make out whether your app was written in Java or C/C++.

Those you doubt, may download eclipse IDE for their favorite platform. It itself has been written using SWT and by and large is one of the best IDE ever. Only if there were a GUI builder for SWT, it would be perfect RAD tool.

Re: "Swing programming coming along so well" Until not so long ago I had to use Celeron 400 w/ 128 MB at work. And, you know, Swing DID NOT really swing in there...

Okay, I'll bring it up now: IBM's SWT is great. I've been using Eclipse lately under gnome2 and it's wonderful. Nice native look and feel (great anti-aliased fonts) and very responsive.

If you don't know, Standard Widget Toolkit (SWT) is a java GUI framework that uses JNI to call the native OS windowing API. It's an excellent example of how java can successfully be used for client desktop applications. IBM developed it for the open source Eclipse IDE.

If your looking to Java for cross-platform development and cli is not your thing, Eclipse is a nice IDE that works nicely on windows and linux. Its also open source.

The SWT engine in Eclipse seems pretty cool - rather than using Java's standard slow SWING engine you get a toolkit that passes through to the native UI, which results in a much more responsive application.

AWT/Swing are still too slow. Even with the latest release.

For reasonable GUI performance SWT is the way to go. The object model approximates AWT's so there's not a huge learning curve if you want to experiment.

It's called SWT, Standard Widget Toolkit.

Find it here, towards the bottom.

-SS

In the server side world, configurable logging combined with debugging tools has been the best for me. The debugger in Eclipse is pretty good at this. Combined with log4j, it makes a really nifty tool.

If you do Java, try Eclipse. It made me switch from 4+ years of Emacs!!! :) I know Eclipse also supports C++, but I never tried it, so I don't know how good the C++ support is.

Well, we know that, but you'll see that whenever cross-platform issues come up, the solution proposed is usually 'recompile it, dummy'.

And layers like IBM Eclipse SWT are half-way between universal top-to-bottom implementations like Swing and semi-portable toolkits like Qt.

Most of the time, when you free native resources owned by a Java object, you do so in the "finalizer" that the GC calls when it's about to free your object. A finalizer is analogous to a C++ destructor and is called ClassName.finalize().

Never rely on finalizers for reclaiming resources or your program's behavior is undefined. You can't control when the garbage collector will run the finalizer, and if there's plenty of memory it may never run. Scroll down to the middle of this page for more details on why you shouldn't release any sort of limited system resource in finalizers. (Except for memory.)

Get busy with SWT then. SWT is designed to do exactly that (bind native widgets to Java), and is open source.

Have fun!