applications written in JAVA, like Borland's JBuilder, is always growing in time by the memory occupied untill completely stuck. There is no way out but periodically restart JBuilder What are they irreversably accumulate?
My java applications don't do this. :-) I've seen some applications that grow big in memory, but they always level off to some working set consistant with the supplier's platform recommendation. I'm not using JBuilder, so I'm not sure what you are describing in this case. Is it that the total amount of memory that the operating system allocates to the Java virtual machine running this Java application keep growing, eventually causing thrashing at the operating system level, typically slowing down everything running on the system. The amount of memory allocate to a JVM can usually be specified as a start-up option for the JVM. JVM's don't necessarily garbage collect as long as they are well below this limit. Perhaps the limit used to run your application is too high compared to the amount of physical memory on your machine. If you set it lower, you increas the risk that you application will run out of memory. But but may be set very high to allow your program to handle much larger jobs than you typically need. (I wonder if specifying "incremental garbage collection" might help with this.) It could also be the case that the program has a memory leak, failing to drop references to objects no longer needed. But I doubt that's the case for JBuilder.
I was talking talking about running applications already written, not ones we can modify. If the program has options to cause it to manage memory more tightly, perhaps using System.gc(), that's great, but otherwise, the Java environment runtime options may be the only controls you have.
Hei, FEI & John, I refer to IDE JBuilder of different versions (Professional, Enterprise, Personal, vers.4, vers.3, vers.5). It is the same both Windows and in Linux (Mandrake, Debian of differrent versions). I do not mess with the code of it. This is the problem experienced by all my colleagues. The JBuilder process/application just occupies more and more space till OS becomes very slow.
I'm pretty sure that most of JBuilder is in Java. In the Windows version there is a .exe file and several .dlls, but they're not very big - there's a 16-meg jbuilder.jar file in the lib directory that looks like it does most of the work. Moreover, JBuilder looks like a swing application. At least, it does if you go to Tools -> IDE Options -> Browser -> Look and select "Metal". For me this looks like a dead giveaway that they're using the javax.swing.LookAndFeel classes to control appearance. I suppose it's possible that some other platform now supports the notion of look and feel, but I doubt it. For the original question - I don't know. I use JBuilder 5 Pro all the time, and don't notice any problems. I've always had at least 256 Mb in my system though - are you running with notably less than that? Or perhaps you're working with features or classes that I don't - I rarely create GUI's, for example. Do you close tabs and windows that you don't need? That's the main thing I can think of that builds up over time if you're not careful.
RAM: 128 MB and more (my colleagues have up to 256 MB). I deal with a Swing, JDBC (on remote server), etc. and a lot of deprecated classes But unloading any files or applications does not help. It is JBuilder... Anyway I recalled from after your reply that there platform-dependent, heavey-weight, peer, poor Java-native-classes matches, bugs, etc. .... About what I really wanted at the morning go to to Swing/AWT forum but did not have time. I may test that question here. My book on AWT has phrase:
I do not quite get why should we have window and cannot place directly. I am rereading dozens of times some available to me phrases about heavy-/lightweights, peers.... May anybody give me good links on the mess?
JBuilder is a Java application. It may contain a little bit of C/C++, but it's mostly Java. It is possible to get memory leaks in Java. Basically, if you keep pointers to objects around, you never GC those objects and they build up over time. I haven't heard of any memory leaks in JBuilder. You can try Borland's site, as well as the JBuilder newsgroups. --Mark
Mark Herschberg, author of The Career Toolkit
Actually, the company I work for has had this problem with JBuilder too... it's not because JBuilder is written in Java, it's because any time you access ( i.e. open, compile, run, etc. ) a class file, it (or a reference to it or something) stays in memory... so if you are on a really big project that has alot of classes, alot of memory gets used up keeping track of all the classes. The worst is when you do a system re-compile... all the classes in the whole project are accessed.
I think that Borland (or Inprise or whoever owns JBuilder now... ) could probably fix this by un-cacheing classes completely, or adding some scheme to unload classes after a while, but it would probably slow down other aspects of the system, though it would be nice to at least choose to cache classes or not, if you were having this problem... in fact, maybe in newer versions of JBuilder you can... we use v.4, so I can't speak about newer versions.
Write once, run anywhere, because there's nowhere to hide! - /. A.C.