I am totally baffled about this. I myself have a M.Sc. in CompSci and I have had no trouble at all getting a job (this was one month ago). During my education I was contacted several times by head hunters companies but turned them all down. I have had job scouts from US companies offering me jobs (and work permits)
A few months ago I compiled a list of the 3 companies I most wanted as job at and sent 3 applications (there were no job postings!) and got a job offer from all three after the interviews - so I must say getting a job couldn't be easier.
And it is the same with all my friends.
It might be that this is in Denmark. Here a B.Sc. or shorter education will end in unemplyment but a Master from one of the good universities will certainly not. SO if you are in the UK then move over here we have a high shortage of highly skilled IT people.
>> The present Java games are not bad. But they are the same league, like games written in Flash are. Hard to imagine a Java title would show up in the games top 10, and this mainly due to the fact, that most top titles try to really use the hardware at its limits, thus performance is an issue.
Examples of game made in Java that has been on the top ten:
* Who wants to be a millionare
* Vampire - The masquerade
* IL-2 Sturmovik
The last two had very good performance. Note that none of this was made in "pure" Java but in a mix, as suggested in the report.
lol.
I am happy you found it useful.
Personally I bundle the VM with my own projects and then let it be installed as part of the InstallShield procedure and put it in a sub directory of the main application. This way the end user will never know Java was used and Java will not interfere at all with the system itself. A recent game that used this approach was IL-2 Sturmovich (I haven't tried it myself)
Feel free to mail me directly if you want discuss further. (jacob@marner.dk)
This is why I in my report recommend that you bundle your own JVM with your app. That way you can put any of your DLLs in the same directory as your javaw.exe, you are sure it is only started with your app, and you are sure that the JVM behaves exactly as during your own tests. Different JVM has different performance characteristics and take different non-standard parameters, so you can play safe only by bundling your own JVM.
BTW, I have heard several people complain that they couldn't get the Java webstart to work (as users), so I don't consider it stable enough for production use.
I considered splitting up the discussion so the library, language and their implementations was discussed seperately, but I decided against it in the end.
The purpose of the language/library/implementation comparison of C++ is in chapter 5 to make it clear what differences the programmer has from a productivity point of view. Here it is irrelevant whether something is library or language. It is the whole that is interesting.
And for the benchmarks. Here the library is purposefully attempted avoided (as possible). This is written on page 49:
"If computational intensive libraries are used then the exact same libraries should be
used in both cases. If this not possible then the libraries should not be used."
When asking a question: "Can I do X in Java?" and X is something that requires access to some piece of hardware the answer is always that it is possible via JNI if not via the Java standard library.
You should not feel limited by the Java standard libraries - if there is something you miss it is easily wrapped an accessed via JNI in a few minutes. If you can access it from C++, you can access it from Java.
So for the specific questions:
>> How easy is it in java to control the floating point settings of the FPU such as rounding and accuracy? 3D physics simulation is very sensitive to these settings.
I don't know.
>> How can I write a game which is compatible with 3D glasses standards?
Already part of Java3D. Can be done via JNI.
>> Can I access 3D hardware functionality? Hardware lighting or multipass texturing?
Yes.
>> How much control do I have over the garbage collector? I don't want weird pauses happening at the wrong times.
Read the report page 37-38.
>> Can a java program change the screen resolution and color depth?
Yes - possibly only via JNI. My own game at www.rolemaker.dk does this.
>> How much control do I have over sound mixing? Can I use 3D sound?
All you want. Also via JNI.
Wrapping a C++ for use in Java can be done in a few minutes so it is not something that should be considered a limitation.
>> I'm not quite sure what that is supposed to mean -
Native code compilers is also discussed on page 39-40. An example is given on page 65.
>> it's a problem of that particular tool, not of the native executable approach in general.
Correct. This is what is meant.
Jacob Marner
A few months ago I compiled a list of the 3 companies I most wanted as job at and sent 3 applications (there were no job postings!) and got a job offer from all three after the interviews - so I must say getting a job couldn't be easier.
And it is the same with all my friends.
It might be that this is in Denmark. Here a B.Sc. or shorter education will end in unemplyment but a Master from one of the good universities will certainly not. SO if you are in the UK then move over here we have a high shortage of highly skilled IT people.
Examples of game made in Java that has been on the top ten: * Who wants to be a millionare * Vampire - The masquerade * IL-2 Sturmovik
The last two had very good performance. Note that none of this was made in "pure" Java but in a mix, as suggested in the report.
Jacob Marner
lol. I am happy you found it useful. Personally I bundle the VM with my own projects and then let it be installed as part of the InstallShield procedure and put it in a sub directory of the main application. This way the end user will never know Java was used and Java will not interfere at all with the system itself. A recent game that used this approach was IL-2 Sturmovich (I haven't tried it myself) Feel free to mail me directly if you want discuss further. (jacob@marner.dk)
Basically yes. Using Java is not nothing or all. My recommended approach is to mix it to get the best of both worlds.
This is why I in my report recommend that you bundle your own JVM with your app. That way you can put any of your DLLs in the same directory as your javaw.exe, you are sure it is only started with your app, and you are sure that the JVM behaves exactly as during your own tests. Different JVM has different performance characteristics and take different non-standard parameters, so you can play safe only by bundling your own JVM.
BTW, I have heard several people complain that they couldn't get the Java webstart to work (as users), so I don't consider it stable enough for production use.
Yeah, cyborch is right. Read about it at LoadLibrary at MSDN: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dllproc/dll_1o8p.asp
I considered splitting up the discussion so the library, language and their implementations was discussed seperately, but I decided against it in the end.
The purpose of the language/library/implementation comparison of C++ is in chapter 5 to make it clear what differences the programmer has from a productivity point of view. Here it is irrelevant whether something is library or language. It is the whole that is interesting.
And for the benchmarks. Here the library is purposefully attempted avoided (as possible). This is written on page 49:
"If computational intensive libraries are used then the exact same libraries should be used in both cases. If this not possible then the libraries should not be used."
So I am comparing apples with apples.
This is explained in section 6.3.2 on page 36-37 of the report.
When asking a question: "Can I do X in Java?" and X is something that requires access to some piece of hardware the answer is always that it is possible via JNI if not via the Java standard library. You should not feel limited by the Java standard libraries - if there is something you miss it is easily wrapped an accessed via JNI in a few minutes. If you can access it from C++, you can access it from Java. So for the specific questions: >> How easy is it in java to control the floating point settings of the FPU such as rounding and accuracy? 3D physics simulation is very sensitive to these settings. I don't know. >> How can I write a game which is compatible with 3D glasses standards? Already part of Java3D. Can be done via JNI. >> Can I access 3D hardware functionality? Hardware lighting or multipass texturing? Yes. >> How much control do I have over the garbage collector? I don't want weird pauses happening at the wrong times. Read the report page 37-38. >> Can a java program change the screen resolution and color depth? Yes - possibly only via JNI. My own game at www.rolemaker.dk does this. >> How much control do I have over sound mixing? Can I use 3D sound? All you want. Also via JNI. Wrapping a C++ for use in Java can be done in a few minutes so it is not something that should be considered a limitation.
>> I'm not quite sure what that is supposed to mean - Native code compilers is also discussed on page 39-40. An example is given on page 65. >> it's a problem of that particular tool, not of the native executable approach in general. Correct. This is what is meant. Jacob Marner