PDA

View Full Version : Favorite IDE for Java


jcrox
01-23-08, 10:12 AM
I'm just starting the 3rd and final java class this semester, Enterprise Java, and we can actually finally get away from JEdit and use any IDE we want. The instructor suggests NetBeans or Eclipse. What do you guys use?

rhink
01-23-08, 07:58 PM
I've used JBuilder and Eclipse.... have a bit of a preference for JBuilder, but it does have some irritating bugs/quirks.

supra
01-23-08, 08:18 PM
i use Jcreator http://www.jcreator.com/

Harnagel
01-23-08, 08:30 PM
+1 for jcreator

stncttr908
01-23-08, 08:40 PM
I was always an Eclipse user, but JCreator looks very nice. Thanks for the link guys.

jcrox
01-24-08, 10:06 PM
i use Jcreator http://www.jcreator.com/

I'll give it a try this weekend

Absolution
01-25-08, 04:53 AM
JCreator is written entirely in C++, which makes it fast and efficient compared to the Java based editors/IDE's.

This makes me giggle a bit. "We don't use the language you will program in because its slow". yaya, java is nice though :)

That editor looks a lot like visual studio.

jcrox
01-25-08, 09:10 AM
This makes me giggle a bit. "We don't use the language you will program in because its slow". yaya, java is nice though :)

That editor looks a lot like visual studio.

That is kind of funny but, after 2 semesters of being forced to use a highly modified version of JEdit, I'm just happy to have an IDE where I don't have to type out every single damn getter/setter :D

Zhivago
01-25-08, 11:23 AM
That is kind of funny but, after 2 semesters of being forced to use a highly modified version of JEdit, I'm just happy to have an IDE where I don't have to type out every single damn getter/setter :D


I speak every now and then with the original creator of jEdit on freenode IRC - cool guy. (I use Eclipse for the record.)

Also, why does the false belief that Java is slow compared to C++ continue to persist? That used to be the case, but not for some time... check out some performance benchmarks sometime you guys.

If it is slower in some cases, it is most likely due to bad programming practices like disregarding the cost of object creation.

rhink
01-25-08, 06:02 PM
I speak every now and then with the original creator of jEdit on freenode IRC - cool guy. (I use Eclipse for the record.)

Also, why does the false belief that Java is slow compared to C++ continue to persist? That used to be the case, but not for some time... check out some performance benchmarks sometime you guys.

If it is slower in some cases, it is most likely due to bad programming practices like disregarding the cost of object creation.

Problem is a lot of API's SUCK HORRIBLY for object creation, and you can't really control that... in which case C++ will blow it away (stack allocation vs heap allocation). I've seen a single call to unpack CORBA objects create about a zillion tiny objects.... and consume a huge majority of that app's execution time, too. The design of java kind of encourages you to create gobs of little objects without really thinking about it. Swing is bloated and slow as well. If it's all code you can control, it's not too bad. But the biggest performance issue is the non-determinism of the garbage collector.... though even that can usually be beaten into submission with proper tuning. Java can usually be "fast enough" (esp in 1.5 and 1.6... performance of some code I was working on doubled when we moved from a 1.4 jre to 1.5), though it's real difficult to get a direct, 1:1 comparison for performance, since it's not like you can just recompile your java code with a C++ compiler using all the same API's and such.

rhink
01-25-08, 06:03 PM
This makes me giggle a bit. "We don't use the language you will program in because its slow". yaya, java is nice though :)

That editor looks a lot like visual studio.

A lot of people go "huh?!" when you tell them the java runtime is written in C/C++ :p

They're all just tools.... C++ has advantages... so does Java. Whatever. Pick what is appropriate for the task at hand, and/or what you're comfortable using.

jcrox
01-25-08, 10:47 PM
But the biggest performance issue is the non-determinism of the garbage collector.... though even that can usually be beaten into submission with proper tuning.

There is a way around that now apparently

http://java.sun.com/javase/technologies/realtime/rts/

Harnagel
01-26-08, 07:27 PM
Also, why does the false belief that Java is slow compared to C++ continue to persist? That used to be the case, but not for some time... check out some performance benchmarks sometime you guys.

If it is slower in some cases, it is most likely due to bad programming practices like disregarding the cost of object creation.

It's funny, several years ago I wanted to test how much slower Java ran on my computer compared to C. So I wrote a little porgram that looked for prime numbers using the exactsame algorithm in both languages and put a timer around the call. Then I let it run for ~10sec, ~1min and ~30min. They were both almost exactly the same speed.

I don't remember which C compiler I was using, and it may not have been the fastest, but the results still surprised me considerably.

rhink
01-27-08, 07:40 PM
There is a way around that now apparently

http://java.sun.com/javase/technologies/realtime/rts/

real-time java is tricky and limits the platforms you can run on (Sun's implementation is Sparc Solaris 10 only, IBM's uses real-time linux). The RT JVM's are also not free (last I checked, it could cost thousands of $$$ per seat). If you don't have hard real time requirements, it seems like a lot of pain to go through just to get the garbage collector under control. It's mostly for applications where people could get hurt or die if the system is late responding to a task (for example, air traffic control). It's totally inappropriate for applications where application freezing is merely annoying (like a game).

The concurrent mark/sweep collector (a command line option in recent standard JVM's) does an ok job of limiting pause times in the GC (it's probably appropriate for the majority of applications out there), but it increases total time in the GC a bit.... and it can take a fair amount of fine tuning to get the pause times under control, especially if you need rather low pause times.... and it still doesn't guarantee you won't occasionally get a full GC that could take seconds or minutes depending on the app.