> Apple, on the other hand, seems to have no desire to cater to people who are alright with a laptop that has only an hour of battery life and weighs 7 pounds
Actually I have a late 2008 17" MacBook Pro. It gets 7 hours on one chipset and about half that on another chipset. Apple ditching the power segment is very, very recent. This is why I made my post, what is the point of upping the resolution to a beautiful Retina display if the VRAM is not upped as well?
With regard to battery life. Apple has the option that others do, and Apple itself has already done in my existing Macbook - have a low power graphics chipset for lightweight uses and a decent graphics chipset for those that don't want to wait overnight to get shit done and a battery life of an hour is fine (like me).
Yes, I may be a niche user. It used to be Apple hardware was the choice of this niche. Now they have dropped the performance crown and I'll probably upgrade to an Elitebook with lots of Video Ram (and probably by the time I get one, a Retina display too). I'll miss OS X for sure, but since I've been using Linux for nearly two decades I'm sure I can 'hold my breath long enough' to go back.
So, IMHO Apple were not clever to increase their Retina display while not having a corresponding increase in Video Ram.
What you are missing is that the parent of my post was talking about how good the Retina display was. My point is that the Retina is overrated because despite the massive increase in pixels the VRAM of the MacBooks is actually lower than comparable-cost laptops from other manufacturers (eg. the HP Compaq line). I then gave an illustration of a particular use for more video RAM - a sim I'm developing. I'm sure there are other power users that actually need more laptop power than just rendering their Facebook page at higher resolution.
> They're not interested in chasing "trely powerful users of laptops" -- they're interested in chasing as many people as possible
Absolute bullshit - your argument is only true for PC makers. Apple are not interested in the masses at all, and even a casual examination of their history shows they never have been with Macs. They are interested in the high-end, high-margin segment that are willing to pay top dollar for good gear. This includes me. This is why I find their lack of video ram so suprising, hence my post.
> Then why are you concerned about using a Macbook?
Because I want to use my Macbook to do a flight sim on my comfy lay-z-boy chair while outputting to my bigscreen TV. It would be nice if newer MacbookPros came with more video RAM.
Apple currently has the high resolution screens. Too bad you can only get 1GB of video RAM on the MacBook Pros though. What is the point of having such a high resolution screen if you run out of VRAM for textures etc? I'm thinking about a Retina Mac to replace my existing Mac but at the lack of video ramm is putting me off.
Why does this matter? Because I'm developing a cross-platform OpenGL flight simulator and I would like to have plenty of Video Ram to go around (many flight sim gamers have very high end Windows rigs with 2-4GB of Video RAM, and this is my target [TBH, I don't care about those who want to game on less capable hardware - profit limiting I know, but I'm writing the sim for myself first and foremost and I have great hardware that is poorly utilized by many mainstream games]).
So, my point is while Apple has a lovely display resolution that will probably soon be matched by others. Other laptop manufacturers (eg. HP) produce machines with 2 GB of Video RAM, which is unlikely to be matched by Apple (none of their latops have more than 1 GB of RAM, Apple don't seem to be interested in trely powerful users of laptops - I guess that's what they have the Mac Pro for - but it doesn't help folks like me).
Correct. Turns out that the 'Raptor' problem is, in fact, related to incorrect inflation of the "Combat Edge" chest corset of G-suits. This incorrect inflation also occurred on F-15s and F-16s but no one noticed. Only on the F-22 was it noticed/significant.
> Still, the vendors of things which require badly written java to work have plenty of blame to share too.
Require? don't you mean vendors implement and distribute things in badly written Java. How is this in any way different to crappy apps written in any other language? Have you never seen a well-written and robust multi-platform Java app? they do exist (hint: I produce them:)).
FYI the current year is 2012. The 90's were quite some time ago. If you are a windows user consider the change in quality/reliability/functionality from Windows 95 to Windows 7 today. The same is true of Java (and Linux, and Mac,....). Your data point is rather old and rather out of date for this particular issue.
> We have a ton of server-side java *crap*. It is all crap. I have never seen a java server app that did proper logging-- seems all server-side java coders think uncaught exceptions leading to stack traces are "super cool".
Exception stack traces are usually very handy in diagnosing rare faults. Java's 'chained' exceptions are *exceptional* in helping (terrible pun intended). Stack traces have their place. The problem is with the coders for the software you are having to maintain. I certainly write very informative exception messages at the point of failure (fail fast, and collect up all the information you can before you throw). Quite often I'm also able to include a message on what went wrong and what should be done to fix it (eg. if there is an issue that I can't handle as a programmer, such as environmental resource exhaustion cases like network-down, or out-of-disk; in addition to the usual bad input validation).
The problem is not that the coders leave exceptions. The problem is that they are not thinking of what could go wrong at each step of processing and either failing fast (reporting before getting into an inconsistent state, and remaining in a safe state ready to process the next request) and what outside the system can screw things up (environmental problems). If you think this is unique to Java programmers then I hope you get to look after big server-side C++ systems some day where you get a core dump with no symbols. Joy.
> On the client side, things like the java app to manage Brocade FC switches will sometimes show 90% of the zones missing! Oh, you kill all java instances and re-run it, and all is cool. Yeah, java is great.
I think what you mean to say is that Brocade are useless with this app (that is, despite your frustration please get some perspective). Don't blame Java just because it is accessible enough that morons can use it. (I've done a lot of hardware interfacing in the past and I have to say that letting hardware guys write code is nearly always a disaster - at least as much as letting a software guy like me build hardware systems [it works, but it is not elegant like an experience hardware guy would do]).
Amen to your post. As another developer I certainly respect your skill and commitment to quality. Most developers (no matter what language) don't plan on giving themselves informative messages (eg. what was the failed value, what was expected/the range of valid values, what other related values are there).
> Face it, for any real program it's "write once test everywhere"
Yes. This is why we write unit, integration and system tests as part of development (this is an accepted part of Java development these days). Fortunately once you have these tests the testing of any new platforms and any code enhancements is effortless. You do Test Driven Development (TDD) don't you?
> Tell me with CONFIDENCE that your "cross-platform" java code is gonna run without failure on OpenVMS's java implementation.
You sound like you require Java to work without a developer ever having to their test suite against the target platform. Incidentally, what Java Runtime Environment implementation are you using on OpenVMS?
Great point. That is hardly unique to Microsoft (although MS does have enormous resources that make such killing of employee initiative more gratuitous).
Here's a hint. To fix your problem you have to work with the CSS style - *this is exactly the same as if you were working with hand-rolled Javascript*. The fact that GWT has generated code doesn't really enter into it.
> Eventually something will go wrong, even something small (like 'why is this box displayed 5 pixels to the left in IE9???')
Yes, well the IE series is the bane of anyone working with CSS - they always have to do it a little different to the other browsers (it is common for some simple tags to work fine in lots of variants of Firefox, Chrome and Opera, yet IE will do something retarded with the same markup). It is a shame corporates are so behind the curve they insist on uniform use of IE when they could just as easily choose a much more standards-conformant browser.
So I think you ought to put the blame where it is due, with IE.
On the other hand, I completely understand your frustration with working with someone else's codebase. It is not the way you would have done it. We all feel that way when having to maintain someone else's code. However, do you think you'd really feel any different if you'd picked up a bunch of PHP or Javascript spaghetti? I like GWT not because it is good, but because it is the least worse way of getting a team to produce nicely interactive applications on the web (IMHO).
> You THOUGHT there were no race conditions in your code, but you couldn't test them, so you had no idea.
Actually, it's not that hard to write unit tests for race conditions (and the synchronization that prevents them). The tests may take some time to run, but that does not mean it is impossible. I'm wondering why you had no idea about this?
> It's EASY to do stuff that won't work the same on every OS.
I suggest you go back and re-read the comment you quoted. What the original poster said was that
So far your comments are akin to the old joke, "Doctor! doctor! it hurts when I touch my eye! so don't touch your eye.". Not every style of writing Java will produce the same results on all platforms. This should be a surprise to no-one experienced in the field. However, with proper testing it is entirely possible to write Java programs that will execute the same way on different platforms. I manage to do this, so I'm struggling to see what your argument is, apart from some alarmism (of someone with a different pet language? something you think is a better multi-domain cross-platform solution than Java?).
> Start up a bunch of threads and your Java program is NOT going to behave the same on every platform.
This is because a threaded application is non-deterministic. This is true for C and C++ programs as much as for Java programs. So I don't quite get what your point is.
> That's FUNNY. I've found a bug in a java program that failed because the vendors's version string was malformed.
Please elaborate as I'm curious about this. Note that I didn't say Java was bug-free (no non-trivial piece of software is, and the Java platform is far from trivial). Also, why would you rely on a vendor version string in the first place? sounds a little dodgy to rely on informational strings that are not actually part of the API. Furthermore, you found a bug in Java, big deal. Try and find a development platform that doesn't have at least some bugs in it (and the one you found is pretty trivial).
JInput supports all devices I have yet thrown at it on Mac, Linux, Windows (which is Saitek Rudder Pedals, Thrustmaster F-16 MFDs, Thrustmaster Warthog Hotas, Thrustmaster Cougar HOTAS, lots of different mice, lots of different keyboards, a PS/3 DualShock controller [a passable budget replacement for a 4-axis HOTAS]). The only thing that JInput couldn't do is work with my TrackIR 5 head tracking system. Fortunately there is an excellent project called linux-tracker that allows you to use the TrackIR 5 on Mac and Linux - although you have to do the Java integration yourself. linux-tracker also has some support for cameras. Next on my list is using OpenKinect to support Kinect for headtracking in my sim (means no stupid reflector headgear or headset clip like the TrackIR), fortunately OpenKinect already includes both JNI and JNA (much better) bindings for Java integration.
With regard to microphone integration I haven't done anything with that myself. JOAL is good for outputting sounds in a cross-platform way but I haven't even looked to see whether it does input (JOAL is a wrapper around OpenAL).
JInput isn't perfect though. It doesn't register new devices once initialized, which someday I hope to contribute back to fix this. If a device is plugged in when you initialize JInput in your program then it works really well.
Bro, you simply have a bias against Java and this means you are not reasoning fully. Admit this to yourself. People can (with some effort) write cross-platform C and C++ apps, yet people often write apps that fall over with new service packs to their operating system. Yet you choose to blame a particular technology rather than accept that , "You can write bad FORTRAN in any language".
> I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
Is that your argument? Just because corporate developers (including a lot of C# guys, but there are always exceptions) are often morons doesn't mean Java blows - these guys can and do butcher any technology when they build stuff (hell, even after giving one guy proper code for calculating any date he come back with his shitty VB.NET that was an abomination and had so many holes).
I've written a *lot* of different systems in Java. From embedded, web, graphical, network, rich client etc and the version gotchas (there are minor things you learn to avoid) are nothing in Java compared to the C, C++ and C# systems I used to work on. Hence, my statements.
This is no different to the ActiveX controls that are floating around (eg. some banking access programs), or all the Internet Explorer 6 sites around. It has always been possible to write stuff so it is not to tied to a particular setup, or at least to limit the platform specific bits. It is surprising that an applet can't be rewritten - they're usually not that complex (and getting unit test coverage during maintenance would go quite far).
> With the caveat that you only do things the underlying OS can handle(though this is hardly unique to Java).
Huh? sorry, I'm missing the point here. Hard to do stuff your O/S doesn't as an application programmer. However, if you meant to say that Java only has a common subset of functionality across platforms, then that is a fair comment. I find that the functionality is good enough to make great programs.
> But then again if you are doing server side Windows you probably aren't a good coder to start with.... \
Most Java coders don't get to choose their customer's infrastructure. You are right in that a good Java coder knows how to develop for more than just one platform.
GWT ain't perfect. But I sure as hell find it better than the alternatives. Frigging around with browser-specific Javascript still has to be done sometimes, but doing everything in it is madness (kinda like the idiots who used to insist on working with a bunch on inline assembly rather than embracing C++). I'd rather adapt my Java style appropriate to the target (after all, I have to do this when I also program for Android) rather than be inflexible at the cost of increasing my own workload and making a Javascript maintenance nightmare for others.
Usually there is only a problem when your application server (I'm looking at you, stinky Websphere) relies on a particular vendor's implementation of Java (eg. IBM JDK). With recent Sun/Oracle Java Runtime Environments (that is: Java 6, which is around 5 years old; and Java 7) applications usually run flawlessly (at least, mine do - and I'm doing all the usual Java funky stuff: radar, roadsign and head tracking hardware device control, networking, web, 3D graphics, rich clients, etc).
As a current practitioner in the field I wonder whether your experience is from a long time ago (and polluted by the experience of using software that was based on Microsoft's awful [and deliberately incompatible - which they lost the famous lawsuit over] Java implementation from a long time ago).
This is simply not true for code written by a professional and competent Java developer (note: part of my consulting gig means I code Java on a professional basis).
If you write only to the public APIs then Java truly is Write-Once-Run-Anywhere (although some bad Java developers use internal functionality that can change between Java versions - I'm guessing that perhaps these folks are used to coding to the Undocumented APIs of Win32 that you used to have to use to get things done). In Java you shouldn't do this. IIRC, Sun created around ten thousand unit tests to ensure Java worked correctly on each platform (wonderful, they did all the porting and port testing effort so Java developers don't have to).
Aside from my professional coding (where Java written on a Mac works flawlessly when deployed to Linux and Windows servers) in my spare time I'm working on modern jet air combat simulator in Java. The same Java+JoGL code works flawlessly on Mac, Linux and Windows. Any differences are in capabilities/performance of individual graphics cards (AMD/ATI vs NVidia).
This article about being able to write Java for the GPU is very interesting, since writing shaders via OpenGL is a little bit of a PITA (there is an impedance mismatch between the conventions of Java, OpenGL and GLSL - it would be fabulous to just write in Java [akin to how I can do this on the Web using Google Web Toolkit]).
So I don't think your statement is really true - except for buggy software written by developers who have bad simple-platform habits.
If you examine modern papers on realistic graphics you'll see there are simple integrals that need to be solved, eg: http://hal.archives-ouvertes.fr/inria-00288758
Bruneton, E, Neyret, F (2008), Precomputed Atmospheric Scattering, Computer Graphics -New York- Association for Computing Machinery- Forum 27, 4 (2008) 1079-1086
By understanding more advanced mathematics you will have more advanced options for solving problems, eg. vector cross product for finding an axis to rotate about, or quaternions for a less intuitive way of doing the same, or differential equations for understanding the mechanics or aerodyamics of your game/ragdolls, statistics for understanding why the investment portfolio you are looking at is cleverly masking the reality of the situation. Or Linear Algebra for solving spatial and AI problems iteratively (the way a scientist would optimize, rather than the discrete way a computer scientist would first approach it). The more advanced mathematics you have the more tools you have at your disposal for solving any problem. Just because most people in today's society have a very tenuous grasp on how nature and artificial systems work dosn't mean that you ought to join them - (applied) mathematics is the tool that you use to gain understanding and solve real problems.
> for example, was the high quality texture compression already in ati/nvidia implementations?
My understanding is that texture compression was not in all OpenGL instances in the past because of patent issues (the S3 company owned a patent on it, and it was known as S3TC). Now texture compression is guaranteed to be in OpenGL because an efficient patent-free implementation has been released and standardized on. This is a big win, especially for fully-compatible Free Software implementations of OpenGL (eg. The long-running Mesa Project).
Slashdot Mirror
> Apple, on the other hand, seems to have no desire to cater to people who are alright with a laptop that has only an hour of battery life and weighs 7 pounds
Actually I have a late 2008 17" MacBook Pro. It gets 7 hours on one chipset and about half that on another chipset. Apple ditching the power segment is very, very recent. This is why I made my post, what is the point of upping the resolution to a beautiful Retina display if the VRAM is not upped as well?
With regard to battery life. Apple has the option that others do, and Apple itself has already done in my existing Macbook - have a low power graphics chipset for lightweight uses and a decent graphics chipset for those that don't want to wait overnight to get shit done and a battery life of an hour is fine (like me).
Yes, I may be a niche user. It used to be Apple hardware was the choice of this niche. Now they have dropped the performance crown and I'll probably upgrade to an Elitebook with lots of Video Ram (and probably by the time I get one, a Retina display too). I'll miss OS X for sure, but since I've been using Linux for nearly two decades I'm sure I can 'hold my breath long enough' to go back.
So, IMHO Apple were not clever to increase their Retina display while not having a corresponding increase in Video Ram.
What you are missing is that the parent of my post was talking about how good the Retina display was. My point is that the Retina is overrated because despite the massive increase in pixels the VRAM of the MacBooks is actually lower than comparable-cost laptops from other manufacturers (eg. the HP Compaq line). I then gave an illustration of a particular use for more video RAM - a sim I'm developing. I'm sure there are other power users that actually need more laptop power than just rendering their Facebook page at higher resolution.
> They're not interested in chasing "trely powerful users of laptops" -- they're interested in chasing as many people as possible
Absolute bullshit - your argument is only true for PC makers. Apple are not interested in the masses at all, and even a casual examination of their history shows they never have been with Macs. They are interested in the high-end, high-margin segment that are willing to pay top dollar for good gear. This includes me. This is why I find their lack of video ram so suprising, hence my post.
> Then why are you concerned about using a Macbook?
Because I want to use my Macbook to do a flight sim on my comfy lay-z-boy chair while outputting to my bigscreen TV. It would be nice if newer MacbookPros came with more video RAM.
Apple currently has the high resolution screens. Too bad you can only get 1GB of video RAM on the MacBook Pros though. What is the point of having such a high resolution screen if you run out of VRAM for textures etc? I'm thinking about a Retina Mac to replace my existing Mac but at the lack of video ramm is putting me off.
Why does this matter? Because I'm developing a cross-platform OpenGL flight simulator and I would like to have plenty of Video Ram to go around (many flight sim gamers have very high end Windows rigs with 2-4GB of Video RAM, and this is my target [TBH, I don't care about those who want to game on less capable hardware - profit limiting I know, but I'm writing the sim for myself first and foremost and I have great hardware that is poorly utilized by many mainstream games]).
So, my point is while Apple has a lovely display resolution that will probably soon be matched by others. Other laptop manufacturers (eg. HP) produce machines with 2 GB of Video RAM, which is unlikely to be matched by Apple (none of their latops have more than 1 GB of RAM, Apple don't seem to be interested in trely powerful users of laptops - I guess that's what they have the Mac Pro for - but it doesn't help folks like me).
Correct. Turns out that the 'Raptor' problem is, in fact, related to incorrect inflation of the "Combat Edge" chest corset of G-suits. This incorrect inflation also occurred on F-15s and F-16s but no one noticed. Only on the F-22 was it noticed/significant.
Just in case you think I'm full of shit, here's a citation quoting USAF sources:
http://www.military.com/daily-news/2012/08/01/air-force-confident-f22-oxygen-riddle-solved.html
With that (apparently 20-year old) problem solved, Raptor is back in the air and back to Top Dog.
> Still, the vendors of things which require badly written java to work have plenty of blame to share too. :)).
Require? don't you mean vendors implement and distribute things in badly written Java. How is this in any way different to crappy apps written in any other language? Have you never seen a well-written and robust multi-platform Java app? they do exist (hint: I produce them
FYI the current year is 2012. The 90's were quite some time ago. If you are a windows user consider the change in quality/reliability/functionality from Windows 95 to Windows 7 today. The same is true of Java (and Linux, and Mac, ....). Your data point is rather old and rather out of date for this particular issue.
> We have a ton of server-side java *crap*. It is all crap. I have never seen a java server app that did proper logging-- seems all server-side java coders think uncaught exceptions leading to stack traces are "super cool".
Exception stack traces are usually very handy in diagnosing rare faults. Java's 'chained' exceptions are *exceptional* in helping (terrible pun intended). Stack traces have their place. The problem is with the coders for the software you are having to maintain. I certainly write very informative exception messages at the point of failure (fail fast, and collect up all the information you can before you throw). Quite often I'm also able to include a message on what went wrong and what should be done to fix it (eg. if there is an issue that I can't handle as a programmer, such as environmental resource exhaustion cases like network-down, or out-of-disk; in addition to the usual bad input validation).
The problem is not that the coders leave exceptions. The problem is that they are not thinking of what could go wrong at each step of processing and either failing fast (reporting before getting into an inconsistent state, and remaining in a safe state ready to process the next request) and what outside the system can screw things up (environmental problems). If you think this is unique to Java programmers then I hope you get to look after big server-side C++ systems some day where you get a core dump with no symbols. Joy.
> On the client side, things like the java app to manage Brocade FC switches will sometimes show 90% of the zones missing! Oh, you kill all java instances and re-run it, and all is cool. Yeah, java is great.
I think what you mean to say is that Brocade are useless with this app (that is, despite your frustration please get some perspective). Don't blame Java just because it is accessible enough that morons can use it. (I've done a lot of hardware interfacing in the past and I have to say that letting hardware guys write code is nearly always a disaster - at least as much as letting a software guy like me build hardware systems [it works, but it is not elegant like an experience hardware guy would do]).
Amen to your post. As another developer I certainly respect your skill and commitment to quality. Most developers (no matter what language) don't plan on giving themselves informative messages (eg. what was the failed value, what was expected/the range of valid values, what other related values are there).
> Face it, for any real program it's "write once test everywhere"
Yes. This is why we write unit, integration and system tests as part of development (this is an accepted part of Java development these days). Fortunately once you have these tests the testing of any new platforms and any code enhancements is effortless. You do Test Driven Development (TDD) don't you?
> Tell me with CONFIDENCE that your "cross-platform" java code is gonna run without failure on OpenVMS's java implementation.
You sound like you require Java to work without a developer ever having to their test suite against the target platform. Incidentally, what Java Runtime Environment implementation are you using on OpenVMS?
Awesome post. Blew 15 modpoints yesterday so all I can do is a: +1 Insightful (moral)
Great point. That is hardly unique to Microsoft (although MS does have enormous resources that make such killing of employee initiative more gratuitous).
Here's a hint. To fix your problem you have to work with the CSS style - *this is exactly the same as if you were working with hand-rolled Javascript*. The fact that GWT has generated code doesn't really enter into it.
> Eventually something will go wrong, even something small (like 'why is this box displayed 5 pixels to the left in IE9???')
Yes, well the IE series is the bane of anyone working with CSS - they always have to do it a little different to the other browsers (it is common for some simple tags to work fine in lots of variants of Firefox, Chrome and Opera, yet IE will do something retarded with the same markup). It is a shame corporates are so behind the curve they insist on uniform use of IE when they could just as easily choose a much more standards-conformant browser.
So I think you ought to put the blame where it is due, with IE.
On the other hand, I completely understand your frustration with working with someone else's codebase. It is not the way you would have done it. We all feel that way when having to maintain someone else's code. However, do you think you'd really feel any different if you'd picked up a bunch of PHP or Javascript spaghetti? I like GWT not because it is good, but because it is the least worse way of getting a team to produce nicely interactive applications on the web (IMHO).
> You THOUGHT there were no race conditions in your code, but you couldn't test them, so you had no idea.
Actually, it's not that hard to write unit tests for race conditions (and the synchronization that prevents them). The tests may take some time to run, but that does not mean it is impossible. I'm wondering why you had no idea about this?
> It's EASY to do stuff that won't work the same on every OS.
I suggest you go back and re-read the comment you quoted. What the original poster said was that
So far your comments are akin to the old joke, "Doctor! doctor! it hurts when I touch my eye! so don't touch your eye.". Not every style of writing Java will produce the same results on all platforms. This should be a surprise to no-one experienced in the field. However, with proper testing it is entirely possible to write Java programs that will execute the same way on different platforms. I manage to do this, so I'm struggling to see what your argument is, apart from some alarmism (of someone with a different pet language? something you think is a better multi-domain cross-platform solution than Java?).
> Start up a bunch of threads and your Java program is NOT going to behave the same on every platform.
This is because a threaded application is non-deterministic. This is true for C and C++ programs as much as for Java programs. So I don't quite get what your point is.
> That's FUNNY. I've found a bug in a java program that failed because the vendors's version string was malformed.
Please elaborate as I'm curious about this. Note that I didn't say Java was bug-free (no non-trivial piece of software is, and the Java platform is far from trivial). Also, why would you rely on a vendor version string in the first place? sounds a little dodgy to rely on informational strings that are not actually part of the API. Furthermore, you found a bug in Java, big deal. Try and find a development platform that doesn't have at least some bugs in it (and the one you found is pretty trivial).
JInput supports all devices I have yet thrown at it on Mac, Linux, Windows (which is Saitek Rudder Pedals, Thrustmaster F-16 MFDs, Thrustmaster Warthog Hotas, Thrustmaster Cougar HOTAS, lots of different mice, lots of different keyboards, a PS/3 DualShock controller [a passable budget replacement for a 4-axis HOTAS]). The only thing that JInput couldn't do is work with my TrackIR 5 head tracking system. Fortunately there is an excellent project called linux-tracker that allows you to use the TrackIR 5 on Mac and Linux - although you have to do the Java integration yourself. linux-tracker also has some support for cameras. Next on my list is using OpenKinect to support Kinect for headtracking in my sim (means no stupid reflector headgear or headset clip like the TrackIR), fortunately OpenKinect already includes both JNI and JNA (much better) bindings for Java integration.
With regard to microphone integration I haven't done anything with that myself. JOAL is good for outputting sounds in a cross-platform way but I haven't even looked to see whether it does input (JOAL is a wrapper around OpenAL).
JInput isn't perfect though. It doesn't register new devices once initialized, which someday I hope to contribute back to fix this. If a device is plugged in when you initialize JInput in your program then it works really well.
Bro, you simply have a bias against Java and this means you are not reasoning fully. Admit this to yourself. People can (with some effort) write cross-platform C and C++ apps, yet people often write apps that fall over with new service packs to their operating system. Yet you choose to blame a particular technology rather than accept that , "You can write bad FORTRAN in any language".
> I'm not a java expert (I'm a C#/RoR guy) but if fortune 500 companies can't get it right, can you really say that java is cross version compatible?
Is that your argument? Just because corporate developers (including a lot of C# guys, but there are always exceptions) are often morons doesn't mean Java blows - these guys can and do butcher any technology when they build stuff (hell, even after giving one guy proper code for calculating any date he come back with his shitty VB.NET that was an abomination and had so many holes).
I've written a *lot* of different systems in Java. From embedded, web, graphical, network, rich client etc and the version gotchas (there are minor things you learn to avoid) are nothing in Java compared to the C, C++ and C# systems I used to work on. Hence, my statements.
This is no different to the ActiveX controls that are floating around (eg. some banking access programs), or all the Internet Explorer 6 sites around. It has always been possible to write stuff so it is not to tied to a particular setup, or at least to limit the platform specific bits. It is surprising that an applet can't be rewritten - they're usually not that complex (and getting unit test coverage during maintenance would go quite far).
> With the caveat that you only do things the underlying OS can handle(though this is hardly unique to Java).
Huh? sorry, I'm missing the point here. Hard to do stuff your O/S doesn't as an application programmer. However, if you meant to say that Java only has a common subset of functionality across platforms, then that is a fair comment. I find that the functionality is good enough to make great programs.
> But then again if you are doing server side Windows you probably aren't a good coder to start with....
\ Most Java coders don't get to choose their customer's infrastructure. You are right in that a good Java coder knows how to develop for more than just one platform.
GWT ain't perfect. But I sure as hell find it better than the alternatives. Frigging around with browser-specific Javascript still has to be done sometimes, but doing everything in it is madness (kinda like the idiots who used to insist on working with a bunch on inline assembly rather than embracing C++). I'd rather adapt my Java style appropriate to the target (after all, I have to do this when I also program for Android) rather than be inflexible at the cost of increasing my own workload and making a Javascript maintenance nightmare for others.
Usually there is only a problem when your application server (I'm looking at you, stinky Websphere) relies on a particular vendor's implementation of Java (eg. IBM JDK). With recent Sun/Oracle Java Runtime Environments (that is: Java 6, which is around 5 years old; and Java 7) applications usually run flawlessly (at least, mine do - and I'm doing all the usual Java funky stuff: radar, roadsign and head tracking hardware device control, networking, web, 3D graphics, rich clients, etc).
As a current practitioner in the field I wonder whether your experience is from a long time ago (and polluted by the experience of using software that was based on Microsoft's awful [and deliberately incompatible - which they lost the famous lawsuit over] Java implementation from a long time ago).
This is simply not true for code written by a professional and competent Java developer (note: part of my consulting gig means I code Java on a professional basis).
If you write only to the public APIs then Java truly is Write-Once-Run-Anywhere (although some bad Java developers use internal functionality that can change between Java versions - I'm guessing that perhaps these folks are used to coding to the Undocumented APIs of Win32 that you used to have to use to get things done). In Java you shouldn't do this. IIRC, Sun created around ten thousand unit tests to ensure Java worked correctly on each platform (wonderful, they did all the porting and port testing effort so Java developers don't have to).
Aside from my professional coding (where Java written on a Mac works flawlessly when deployed to Linux and Windows servers) in my spare time I'm working on modern jet air combat simulator in Java. The same Java+JoGL code works flawlessly on Mac, Linux and Windows. Any differences are in capabilities/performance of individual graphics cards (AMD/ATI vs NVidia).
This article about being able to write Java for the GPU is very interesting, since writing shaders via OpenGL is a little bit of a PITA (there is an impedance mismatch between the conventions of Java, OpenGL and GLSL - it would be fabulous to just write in Java [akin to how I can do this on the Web using Google Web Toolkit]).
So I don't think your statement is really true - except for buggy software written by developers who have bad simple-platform habits.
If you examine modern papers on realistic graphics you'll see there are simple integrals that need to be solved, eg:
http://hal.archives-ouvertes.fr/inria-00288758
Bruneton, E, Neyret, F (2008), Precomputed Atmospheric Scattering, Computer Graphics -New York- Association for Computing Machinery- Forum 27, 4 (2008) 1079-1086
By understanding more advanced mathematics you will have more advanced options for solving problems, eg. vector cross product for finding an axis to rotate about, or quaternions for a less intuitive way of doing the same, or differential equations for understanding the mechanics or aerodyamics of your game/ragdolls, statistics for understanding why the investment portfolio you are looking at is cleverly masking the reality of the situation. Or Linear Algebra for solving spatial and AI problems iteratively (the way a scientist would optimize, rather than the discrete way a computer scientist would first approach it). The more advanced mathematics you have the more tools you have at your disposal for solving any problem. Just because most people in today's society have a very tenuous grasp on how nature and artificial systems work dosn't mean that you ought to join them - (applied) mathematics is the tool that you use to gain understanding and solve real problems.
> for example, was the high quality texture compression already in ati/nvidia implementations?
My understanding is that texture compression was not in all OpenGL instances in the past because of patent issues (the S3 company owned a patent on it, and it was known as S3TC). Now texture compression is guaranteed to be in OpenGL because an efficient patent-free implementation has been released and standardized on. This is a big win, especially for fully-compatible Free Software implementations of OpenGL (eg. The long-running Mesa Project).
citation please of your game.