[TrashMan]

Bah...Carl has goten fat and is out of shape. Besides, wasn't he stuck in the vent?
He can onyl scare n00bs now...especially since I got my plasma rifle of Destruction (+5 vs. Shivans).


Now, where wuz I? Oh yes!
*points at the giant friggin lazer at his moon base*

I want one million dollarz! Or a better nick anyway....

[WMCoolmon]

There's a gc() function in Java as well, which is supposed to run the garbage collector. There's nothing stopping someone from parking a call to it at opportune times (eg after a file load or save has finished) and/or grouping all their 'deallocation' changes right before gc().

Why I'm using Java is because it's a hell of a lot less pain in the ass than wxWidgets was. I can point people to one package they'll have to install, and it's widely enough used that most people will already have it installed. Mac OS X actually comes with a JVM by default. It has fully built-in crossplatform interface and file loading/saving code. The capabilities are also pretty consistent across platforms. It doesn't require that I throw in a bunch of empty macros everywhere. For the most part, debugging is much easier because I can just check the command line for exceptions. Speed is not an issue.

Load time for all retail VPs: 8 seconds
Load time for all BtRL demo VPs: 2 seconds

And it takes around a minute and 30 seconds to write a merged VP of all the retail VPs, compared to 50 seconds if you were just copying all the VPs to the same location. How often do you need to write 1.17 GB worth of VPs, anyway?

I also don't have to worry about providing platform-specific binaries, and I can compile for all platforms on one platform, radically reducing the time it takes for me to go from making some code change to having a new version ready to release. I don't need to worry about #defines to provide substitutions for functions or features which aren't supported on one platform. I don't need to worry about having special compiler flags in the project files for each platform. Hell, getting a project file to work with wxWidgets can be a chore in and of itself. Last time I used wxWidgets I couldn't find decent instructions to get a project to compile with MSVC. And last time I used wxWidgets, I couldn't even get the right-click trigger for a tree object working for Polonius, despite hours of poking through newsgroups and forums and even posting the code in question and trying to get help based on that.

Overall, it's far easier to use Java for something like this, rather than struggle with wxWidgets for who-knows-how-many-hours to get it to work, and then have to deal with getting everybody who actually wants to use the program to install wxWidgets, and keeping three sets of binary releases in-sync and up-to-date.

And in some cases I've found that the automatic garbage collection of Java is a plus, because I don't have to worry about writing extra code to basically do the same thing as the garbage collector.

[karajorma]

There's a gc() function in Java as well, which is supposed to run the garbage collector. There's nothing stopping someone from parking a call to it at opportune times (eg after a file load or save has finished) and/or grouping all their 'deallocation' changes right before gc().

I'm not sure if you're aware of this actually but the gc() method does not call the garbage collector. It tells the system that this might be a good time to call the garbage collector. Whether or not the system responds to that request immediately is a function of that particular implementation of the VM.

That said in most cases it probably will so you're not really wrong in what you said. You should just never assume that the garbage collector will be called.

[Turey]

I've found that Java tends to be good with small and/or fairly straight-forward programs. One of the best features of Java is the large supply of built-in libraries that do most of your work. Why bother writing your own collection class when you've got ArrayList and friends?

On the other hand, if you find that you're going to have to re-write a lot of the Java Library, or that you're simply not using much of it, then the argument to move to another language becomes much more convincing.

As for the speed issue, it's really not that big of a problem anymore. The more recent VMs seem to be plenty fast. If you're seeing a speed problem, it's likely your code, and not Java. The problem with Java's VMs is that they seem to artificially limit the memory footprint, which causes problems. I wrote a Liar's Dice game in Java recently, and the speed of it WAS a problem: The AI I wrote played so fast that you had to scroll back up and read what happened! (Project requirements specifically stated that we had to use the command line...) I managed to get several hundred million AI players in one game, and had no slowdown. Adding -Xmx1024m to your Java execution line will occasionally do wonders for speed on high-powered machines.

Why I'm using Java is because it's a hell of a lot less pain in the ass than wxWidgets was. I can point people to one package they'll have to install, and it's widely enough used that most people will already have it installed. Mac OS X actually comes with a JVM by default. It has fully built-in crossplatform interface and file loading/saving code. The capabilities are also pretty consistent across platforms.

Java isn't actually as cross-platform as I'd like, but that's not Java's fault. If you're using anything above Java 1.4.2, then you'll get a bunch of "OMG IT DOESNT WURK AND I ALREADY GOTS JAVA!" because Apple doesn't bother to update the version of VM they distribute with OSX. If the major OSes were distributed with the latest Java VM as of the release date, it wouldn't be a problem. I'm sure that Apple's issued a minor version change in the time since 1.5 came out.

[Kazan]

So in other words the problem was solved by good programming. Which is exactly my point. The problem is not a fault in the language so much as the inability of the coders to recognise and code for the languages strengths and weaknesses.


Bear in mind that the same ****ty code would have caused a hell of a slowdown in C++ too. The only difference there is that without garbage collection the entire program would run slowly all the time and the cause would not be apparent without profiling.

the "same ****ty code" would have been fine in C++ because the problem WASN'T IN THE CODE, the problem was in the memory management scheme - what they did was not good programming, what they did was BAAAD programming... creative but still bad - only reason it's justified is they were working around a WORSE behavior of the language.

[Kazan]

turey.. do me a favor

don't talk to me like i'm a ****ing moron - i have the latest JRE on all my systems, if I had a problem running said code (Whih i haven't bothered to try to run) I would have checked that first.

and it's not "my code" i avoid writing java code because java is the plague... a java VM fast? that's LAUGHABLE.. the java VM is slow, absolutely inexecusably slow.  Startup times on hat should only take a fraction of a second to load for what it does, and this isn't "it's the code's fault!" this is good code from good programmers are annoyingly long in java.


and i'm not interested in times it takes to READ a VPs FAT - i want to know load times, how long it takes to WRITE a vp, etc

[WMCoolmon]

turey.. do me a favor

don't talk to me like i'm a ****ing moron - i have the latest JRE on all my systems, if I had a problem running said code (Whih i haven't bothered to try to run) I would have checked that first.

You're throwing a fit and accusing Turey of implying you're a ****ing moron over code you haven't even tried to run yet?

and it's not "my code" i avoid writing java code because java is the plague... a java VM fast? that's LAUGHABLE.. the java VM is slow, absolutely inexecusably slow.  Startup times on hat should only take a fraction of a second to load for what it does, and this isn't "it's the code's fault!" this is good code from good programmers are annoyingly long in java.

Good programmers test their code before accusing someone of being a ****ing moron for suggesting that they could optimize said code.

and i'm not interested in times it takes to READ a VPs FAT - i want to know load times, how long it takes to WRITE a vp, etc

I never posted how long it took to "READ a VPs FAT". I posted how long it took to load the FAT of the 9 retail VPs, convert those FAT to over 6,000 internal class instances representing each of the files/folders, along with various other supporting classes, then use each of those classes to create the 18,000 class instances needed to add those to all three of the entry trees, and finally display the 6,000 entries in the one visible file view tree.

It takes about two seconds to load Maja under OS X, and around a second to load Maja under Windows.

I already posted how long it takes to write a VP.

EDIT: My bad, you weren't accusing Turey of being a ****ing moron, just accusing him of implying(?) you were a ****ing moron. Even more amusing.

[Goober5000]

Kazan, garbage collection hasn't been a serious issue since Java 1.2.  Unless you're writing a real-time or embedded application (in which case you shouldn't be using Java anyhow), Java will run at perfectly acceptable speeds.  Allegedly it can be faster than C++ in some areas, but I haven't seen statistics on this.

Another thing is that you can't write C++ code in Java.  You have to follow the assumptions of the programming language that you write in.  This means that you don't implement function pointers using reflection and callback; you use an interface.  Etc.

What have you written in Java, anyway?

[Bobboau]

IIRC Kaz was forced to use Java against his will, because one of his professors helped write it.

I'm not sure if you're aware of this actually but the gc() method does not call the garbage collector. It tells the system that this might be a good time to call the garbage collector. Whether or not the system responds to that request immediately is a function of that particular implementation of the VM.

oh isn't that lovely, your code performs totally different on different systems and there is nothing you can do about it. this is one of the principal reasons I hate Java on a very intimate personal level, none of your code is executed it's 'interpreted'.

[WMCoolmon]

I'd actually like karajorma to source that comment, the java documentation says (for 1.6.0):

    Runs the garbage collector.

    Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

    The call System.gc() is effectively equivalent to the call:

         Runtime.getRuntime().gc()

Runtime.gc():

    Runs the garbage collector. Calling this method suggests that the Java virtual machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects.

    The name gc stands for "garbage collector". The virtual machine performs this recycling process automatically as needed, in a separate thread, even if the gc method is not invoked explicitly.

    The method System.gc() is the conventional and convenient means of invoking this method.

I haven't used gc() enough (I haven't had to use it at all) to know how accurate the documents are. However, I found this test program which I used under Windows and found that the garbage collector was, in fact, invoked with the gc() call.

Still, that's a relatively minor point (IMHO). It's no different from using something like OpenGL or OpenAL and having to deal with different functionality on different systems. Mostly I just want to know what the differences are on what platforms, I haven't found a site listing them yet.

[Kazan]

openGL and openAL only have differences between different hardware capabilities - the programming interface is still the same and the basic behavior is the same, it's just a "realism" difference.

and bob has it right - i've had to write a lot of java because one of the professors who (is now moving to a school in florida) at my uni helped write part of java

[Flipside]

So would it be safe to assume that if you are creating small applications and 'non-speed-critical' software, that Java is an acceptable, if not very popular, solution? But the moment speed or memory are going to need to be kept at a premium, it's probably better to look for a language with more 'direct' control over the management?

[karajorma]

I'd actually like karajorma to source that comment, the java documentation says (for 1.6.0):

    Runs the garbage collector.

    Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

Let me clarify. I don't remember if it runs the garbage collector itself and that simply returns without doing any collection or if the system decides not to call the garbage collector.

Either way the result is the same. Calls to gc() do NOT guarantee that garbage collection will be performed. Simply that this is a good time for garbage collection to be performed. Pay close attention to the use of the word suggest.

This fact is actually a favourite of the examiners on the certification exams. Which is why I remember it despite not actually having touched Java for quite a while.

[WMCoolmon]

I'd actually like karajorma to source that comment, the java documentation says (for 1.6.0):

    Runs the garbage collector.

    Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

Let me clarify. I don't remember if it runs the garbage collector itself and that simply returns without doing any collection or if the system decides not to call the garbage collector.

That's an important difference. If it runs the garbage collector and the memory can't be freed, that's a whole 'nother ball game from the JVM simply not deciding to try at all. After all, it's not like the garbage collector can add extra RAM sticks to your machine if it reads everything as being in-use; though it might be able to do some defrag work.

Now I feel like Kazan, accusing someone of being condescending. Rather than implying that I'm not paying enough attention to the definition or not reading it right, read the sentences before and after the "suggest" one. Both state with certainty that the garbage collector will have been run, and made a 'best effort' to reclaim memory. Hence I feel like arguing over the interpretation of the definition in the Java API is retarded because it basically contradicts itself with regards to the certainty, which is why I asked what you were basing your comment on.

[WMCoolmon]

So would it be safe to assume that if you are creating small applications and 'non-speed-critical' software, that Java is an acceptable, if not very popular, solution? But the moment speed or memory are going to need to be kept at a premium, it's probably better to look for a language with more 'direct' control over the management?

I think you shouldn't make any concrete judgments based on this thread. The SCP is C-based, which is what attracts most programmers. It's also a game, and most 3D games are written in C/++ because that's been the best solution so far. If you were to go to a forum that attracted mostly Java fellows, you'd probably get people *****ing about the templates library or preaching how Java is so much better because it's so much easier to use and doesn't require libraries.

Bobb has basically admitted to being biased towards the way that Java runs, and AFAIK hasn't done any real coding at all with it. Kazan was forced into doing Java. I haven't done anything much to test Java's speed or memory usage compared to C/C++, nor do I know much about optimizing it. Turey seems to be in about the same boat as me. Karajorma has probably had the most experience with the language, as IIRC he works as a java programmer as his day job.

Sun has gone to some effort to get Java to run on embedded platforms, where CPU usage and memory usage will be at a premium. I haven't researched that at all; I don't know how the performance stacks up against C-based apps.

I would say that unless you're doing something that needs a lot of speed or lowlevel hardware/software access, or you need something that can be portable to other platforms or the web in a flash, you should prefer the language you like the most. If you're in a position where you need speed but want portability or vice versa, figure out a way to run some benchmarks with what you're actually doing. Open a bunch of windows or spit out a bunch of polygons (There are OpenGL and OpenAL wrappers for Java now). Do a bunch of physics calculations.

That is just MHO.

[Flipside]

Thanks for the opinion, the reason I'm asking is because, like all trainee programmers, we'd all love to write a game, even though I'm honest enough to myself to know the chances are my career probably won't go in that direction. I'm learning Java for my second year at Uni, but was basically under the impression that Java was more a 'business language', as in it was designed for writing easily and quickly at the cost of low-level access, but, most everyone tends to polarise themselves to a particular language so it is kind of hard to get a good picture.

I've got the next few months free, which is a rare moment in my life, and I am considering sitting down and learning some C++, from what I've been told, moving from C++ to Java is not that much of a chore at the sort of level we'll be using it at Uni.

I suppose the real decider here for me is the accessiblity of help on the web, GameDev.net etc were very C++ based for a while in the 3D graphics side of things, with Java considered to be a language for writing phone games on.

If I am going to take on a project as massive as a game as a hobby, I suspect I'll need all the help and hints I can find on the net, I've got a pretty good founding in basic coding and design practice, being an ex 8-Bit machine coder, the rules haven't changed, even if the languages have. I already have a pile of DFD's Data Dictionaries, Flowcharts etc I've done over the years, though the chances are none of them will even be relevant by the time I actually sit down and start writing.

Still, it'll be a while before that happens, first job is just to write out some simple software based algorhythms for Matrices and Quarternians and removing cobwebs from 15-year old 3D programming practices

Edit: Though I will admit, I only did Pascal and VBasic this year, nice to see they haven't changed, Pascal is still the worlds most complicated calculator, and Basic is still 'Lego for Programmers'

[karajorma]

I can find lots of comments on the gc() method but pretty much everything I'm finding is from 1.4.2 or earlier. Basically the explanation I was given while studying for Certification was that the gc() method sets a flag telling the garbage collector that it has been asked to run and nothing else. The implementation is completely at liberty to decide what it wants to do with this flag.

IIRC Hotspot and IBM's JVMs did respect the flag. Others might not or might do something different.

For instance.

http://edocs.bea.com/wljrockit/docs142/devapp/codeprac.html

Avoid Calling System.gc()

Don't call java.lang.System.gc(). This method behaves differently with BEA JRockit JVM than with other JVMs. Instead of doing a complete garbage collection, as with the Sun JVM and others, when called by an application running with BEA JRockit JVM, System.gc() behaves depending upon the garbage collector already in use:

    * If you're using a generational copy collector, System.gc() does a collection in their nursery.
    * For all other collectors, it does a collection only if one is needed. In other words, it does nothing special on the call.

Sun are quite strict on the matter in their exams. You'll automatically fail any question in which you say that the gc() method calls the garbage collector.

[Bobboau]

if you are planning on going into games programming, Java is not for you. Java is best for application software, like a tax calculator or a spreadsheet or a word processor, and it's best if you have a lot of platforms you want to support, while C\++ can be very portable it's up to the API writers to make sure it is, this is why I like my C, because ultimately the programmer is in charge. however, there is a trade off in terms of easy vs lot-of-control (and thus an ability to take advantage of hardware). now when I say a lot of platforms, I don't mean PC, Linux, and Mac, a Java program "will" run on any platform that has an interpreter written for it, from a PC to a playstation to a car sterio to a cellphone, and supposedly it will run the same on all them, but that's up to the person who writes the Java interpreter, not you.

now back to my first point, games need a lot of speed and in Java it is designed around you not being able to get to any hardware, it's a "good" thing in the Java mindset that you can't use memory tricks to copy whole arrays of data directly in one call (because Java is object orientation to the max, memory doesn't exsist anymore, just objects and objects need to know how to copy, so you have to go one at a time) for example. I understand were they are coming from, but I think they just took it WAY THE **** too far. you absolutely cannot take advantage of hardware _ever_, this is both due to Java's OO philosophy and the fact that it's platform independent (if hardware is undefined you can't take advantage of it), for things ware cross platform homogony is more important than speed, this can be a good thing (even if I'm uncomfortable with the fact that you are forced not to go low level for a particular platform). for a game of any complexity this is unacceptable.

[Scooby_Doo]

(because Java is object orientation to the max, memory doesn't exsist anymore, just objects and objects need to know how to copy, so you have to go one at a time)

Actually isn't primitives (int..etc) actually primitives in Java unlike C#, Eiffel and Ruby, which int's are objects?

[Flipside]

Well, I have to be realistic and admit that game programming would likely be a hobby, chances are, like 90% of other programmers, I'll end up being into Database development, which I don't really mind, and, in many ways, it's a lot less demanding than working in the gaming market.

I suppose I'd write a game more because it was a game I'd like to play, which sounds terribly conceited, but I suppose it's better than sitting round complaining that there aren't enough what I consider to be 'engaging' Empire Building type programs out there.

I see what you mean about Java, it gives up low level control for compatability, I guess I will have to learn it anyway for Uni next year, but yeah, I think I'll start studying C++ over the next few months, and getting used to using it

Thanks for the advice and opinions