> So what specifically makes Java more reliable?
A combination of factors, like Java always ensuring everything is initialized, like the garbage collector ensuring that resources shared between multiple threads are eventually cleaned up, or not cleaned up too soon, and by setting references to null (aiding the gc) you can avoid the dangling pointers you get in C++ (which gets horrifically difficult in complex multi-threading programs in C++). The other thing is that Java has certain practices and tools that are not so common in the C++ code I encounter from other people. Yes, it is perfectly possible to do Test Driven Development in C++, but I hardly ever see it done - whereas it is pretty pervasive in the Java community and there are a vast number of tools and reporting engines for Java that help you utilize such techniques. My favourite tool of all is JVisualVM which is similar to gprof but you can instanteously attach to any running program/JVM without having to specially recompile your program.
> Java becomes the better choice for new heavily multi-threaded stuff, IMHO.
Why is that?
Thanks for asking. The real problem is when you have heap-allocated resources in a multi-threaded environment. Who owns the shared resource and who is responsible for releasing it, and when? For stuff that you write yourself this is not such a problem (I'd guess most Slashdotters are better than average devs, yeah?), but when you use libraries (especially older ones) then this becomes problematic very quickly (if they have different memory management strategies to yours, eg using wrappers C libraries in your C++). Again, all these problems can be solved when building large, complex C++ applications but when using Java I never have to devote nearly as much brainpower to worrying about these concerns. Instead, I get to devote my effort to the problem domain (which in my case is not simple form-to-database apps but is in fact quite complex physics [eg. simulating the optical transmission of the atmosphere in real time etc]).
So, on Slashdot it seems very fashionable to 'dis' Java as not 'l337' enough (and hence crufty and outmoded C++ is considered more leet), but I find Java an excellent go-to language for a very wide range of problems (webapp using GWT, embedded, and even my rich-client flight simulator).
> I think Swing looks ugly, and doesn't blend in with the native OS
Many people I've made gaming utilities for rather like the Nimbus Look n' Feel (L&F). Perhaps your perception of Swing of the the rather ugly and outdated Metal L&F. I guess with most stuff moving to browser based apps its hard to find modern Swing apps, so it is easy to only think of Swing as the old apps you used to get.
> I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-platform), and I suspect that is the common opinion too.
That is a common but also rather out-of-date opinion. Most applications on Windows (for example) don't look like each other: MFC CTRL3D.DLL apps don't look like WinForms apps that don't look like browser apps that don't look like games (and their custom UIs) that don't look like MS Office not apps from the big providers (eg. HP printer driver control panel, or Adobe, or Symantec etc etc). In short, the lack of nativeness is a bit of a red herring. The problem with Swing apps was not really the Look, it was the Feel. Many developers made the mistake of blocking the Event Dispatch Thread (EDT) in Swing which made it feel like it was a slug and not responsive. When you don't do that (and make proper use of threading) then Swing apps generally are very performant and a delight to use (apart from a few quirks like not-quite-native looking file dialogs in the past; but those things have mostly been resolved now).
> Still, feel free to use it. If it's your strongest toolkit (ie. the one you know best), then it's the best toolkit for you to use.
Thanks:) It turns out that Swing has excellent integration with JoGL so that mixing 2D and 3D components is a complete breeze (and I don't have to write my own midget library to do the 2D stuff, so I get to overlay all the standard Swing controls even in my 3D views - which is vastly better than most of the crappy interfaces people seem to write when they try and mix DirectX/Direct3D with 2D controls). Given the vast number of controls needed in a combat flight simulator it is very useful to be able to pop up dialogs so the users can adjust their axis mappings and commands (eg. flight controls, radar slew, trim functions, countermeasure, sensor pod aiming etc) while still in-game.
The parent posted this:
>"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"
personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there. If you know what you are doing you can do just about anything (although Swing has plenty of flaws still). It was based on that parent comment that I decided to "defensively" elaborate why I consider Java suitable - and IMHO, particularly suitable for massive multi-threading in a multi-platform application (yes, you can do the same in C++, but it is very much a hassle and the libraries change on each target platform; which was part of my point). Hence, I still see Java as the premier choice of platform for my project (which is what the parent of my original post disputed - he could see no use for client side Java; in fact I don't see any economic alternative; C/C++/C#/Python etc are not nearly as suitable for my purposes and intended development timescale).
I considered Unity3d but it wasn't suitable for my particular purposes - and I would still have to code in C++ (which after two decades of use I'm well sick of it).
Sorry, QT is vile and unnatural, IMHO. Effective sure, but unnatural for those used to proper Object Oriented UI toolkits (eg. back in the day Borland's OWL, Swing etc).
The C++ code itself is nothing. What matters is that for each platform you target you need different libraries, and each library has its own idiom. Then you end up contorting your architecture for each set of libraries you are trying to integrate. This is not impossible (I've written lots of portable, complex C++ in the last two decades) but I can tell you it is *vastly* easier, more consistent, and I would argue more performant (since the time I save not fixing dumb C++ loopholes I instead spent optimizing my Java) to use Java.
Flightgear is an admirable bit of software. I looked at extending it but realized after two decades of C++ and a decade of Java I knew which language to base a new *reliable* multi-player, multi-core product on.
So I understand your advocacy for C++. You can certainly accomplish useful stuff in it (and I have). However, I would never start a new forward-looking project in it. Java becomes the better choice for new heavily multi-threaded stuff, IMHO. (and yes, that includes rich clients, which can me made to look amazing using the "Filthy Rich Client" Swing techniques and OpenGL/JoGL).
What would you like to know, specifically? Note that the 2D UI is a minor part of the application, and a "Filthy Rich Client" (Google if you don't understand this term) Swing startup is perfectly fine to start the JoGL/OpenGL main UI.
> Because it sounds a bit... exaggerated.
This is why I am taking to point out that Java is more than adequate for 3D gaming (since all the important stuff runs on the GPU anyway). I find it lamentable that Slashdotters are so anti-Java (and have out of date perspectives) they simply cannot comprehend that modern JVMs are not only as good as C++ for gaming, they are superior in my experience as a indie game developer (for a hard-core simulation; eg. multi-threaded resource sharing in Java is so much easier than in C++ when you are targetting multiple-platforms). I understand that existing game devs with existing C++ pipelines and assets aren't interested in Java, but new games development should seriously consider it - expecially if you want to be as massively profitable as Java games like Minecraft are.
What do you get for a similar search of "Windows"? (that is also another "platform", just as the JVM is). My point is not that Java is without vulnerabilities - clearly it has them - but that calling it "malware" is misleading since anything with a similar large amount of functionality also has a lot of attack surface. So the hyperbole ought to be cut. k?
Ummm, because it is the best cross-platform solution for rich clients out there. If there was something better I would use it, but there isn't (I'm writing a jet combat flight simulator and C++ and C# simply are too much effort to make truly cross-platform; eg. Mac, Linux, Window, Android). If you would please suggest a useful alternative to Java that was cross-platform and I didn't have to go through all the awful porting nonsense of C++ or C#/Mono (been there done that, don't want to do it again) for my flight sim then I'm all ears.
Try a Thrustmaster Warthog HOTAS (Google if it you don't know what it is), TrackIR 5 headtracker, Thrustmaster MFDs, Saitek Rudder pedals, triple 1080p monitors, several Lilliput touch screens and the usual keyboard and mouse. Yes, not everyone's rig is like this, but mine is. This is not meant as bragging, but just a statement that PC gaming is not just keyboard and mouse - even if the vast majority of it is. There are people that are gaming in ways that only a PC can.
This gives me an experience that no console can match.Plus, the console games both have less diversity and less community modding (which can be very creative). Consoles are wonderful for a quick fix of gaming and the low hassle. For more sophisticated games and gamers the PC is a far better choice (eg. I love full-fidelity combat flight sims and Arma 2, there is nothing like these on consoles since the hardware can't hack-it and the console gamers' tastes are not generally as varied as PC gamers, again IMHO).
> I don't have to believe anything you say.
No you don't. But what you could do are check facts instead. Either build a modern program (eg. game) in Java yourself (doesn't have to be big, just a little one - and profile with JVisualVM) or look around on the web for *current* statements that prove or disprove my assertions. I don't expect you to believe my statements based soley on my assertions - I'm confident that if you actually took the time to check you would come to the same conclusions I have: the areas where Java used to be weak and C++ was strong have pretty much disappeared, therefore new development in C++ is unnecessary for the vast majority of developers, therefore C++ is outdated (compared to more modern tools and techniques; this was my original assertion).
> That's exactly the excuse I was talking about. You have no business using loads of RAM for your application. You should use as little as possible to run on as many computers as possible and allow as many other programs to run as possible (instead of just today's). You're not the only program on the computer, after all, and I'm not going to buy a new computer to run your program.
Wrong. Memory is there to be used. In the case of a game it would be negligent not to efficiently use all the resources that were available. In the case of a general application the application should play nicely with others. In my experience even small Java applications do not have a memory footprint that is excessively larger than other complex applications. For system tools you could argue differently but in fact I have created lots of little Java applications for myself in the nature of Unix tools and memory use has never been an issue. Your view is outdated (just like C++ application development).
> You're not the only program on the computer, after all, and I'm not going to buy a new computer to run your program.
Wrong. You don't know the market I'm aiming for at all. In fact, combat flight simmers are not running their sims on their iPhones or tablets. Even consoles are too weak for proper simulation. These simmers often upgrade their machines (or the major parts) every two years. So you see, I'm not aiming for the lowest-common-denominator market as your incorrectly suppose, it is completely uneconomic (not to mention uninteresting) to support low end machines (eg. puny integrated graphics). Once nice thing I will say is that my program runs very very smoothly (so easy to massively multi-thread in Java while sharing resources) and much more reliably on the same hardware than the DCS:Word simulator (you're probably totally unaware about this simulator, which is the current market leader). Unfortunately DCS:World is still in beta stage, but has quite a few bugs (it's written in C++) that cause crash-to-desktop that I simply don't have to worry about in Java (one of the reasons Java was invented). Given DCS:World's predecessors (and C++ games and development practices in general) I think that this will never be fully resolved (again, another reason motivating me to choose Java over C++).
> I neglected to mention how the garbage collector will only clean up when it feels like it and slow down your program. This makes it unsuitable for time-critical programs like video games.
Wrong. There are lots of garbage collectors to choose from. You can get deterministic garbage collection with real time Java. However, I've found the G1 and parallel collectors to be sufficient for my needs (using less than 1% of CPU every 5 seconds or so - as shown by JVisualVM which comes with the JDK; it's like g++'s gprof but much much better). So, here I am, a game developer and you are telling me that the current Java garbage collectors are unsuitable for games? looks like you don't know what you are talking about (I'm starting to get a theme here) since you appear to be basing your statements on outdated information.
Also, people used to blame Java or the garbage collector when there were pauses in Java GUI programs. This occurred when bad developers blocked the Event Dispatch Thread (something competent Java developers are trained/know not to do). This is wrong and borne of ignorance. There is no fundamental problem with latency in Java (well, not worse than the other latencies in your system, like the millisecond-increases in latency in the O/S scheduler when I/O is happening etc).
> The same excuse was used in 2005 with a different previous year. And if Java is so great it should be good for tiny programs, too.
Wrong. I have created small commercial Java programs to run embedded systems on single board computers. Initially I used gcj but it turns out the Sun JDK was fine for this use. The result was tiny (even if using very complex logic). You can do ti
Applets are legacy. I agree with you, WebStart is a vastly better solution (plus, I've noticed that when I converted a heavily-used applet I had written to WebStart it ran around an order of magnitude faster; the browser plugin for applets is relatively slow).
> A malformed JPEG may successfully execute shellcode on one broken image decoder/renderer, simply crash another, and be caught and thrown out by a third. Which thing happens to any given client (visitor to the page hosting it) will depend on the client's software environment: their browser, their OS, whether they use 32-bit or 64-bit, etc. If you want to make it cross-platform, you'll need to not only have an exploit that works on multiple image libraries (or a suite of exploits that together cover all libraries, and some way to tell which one to use), you'll need shellcode that executes on all those platforms (and shellcoding is hard, especially in the face of the exploit mitigations found in most modern OSes).
JPG, or PDF, or PNG, or Flash, or ActiveX, or Javascript or browser or TCP stack implementation... etc vulnerabilities are pretty common. Yes, you have to do more work than put up a single malicious applet, but it is not that much harder to put up half-a-dozen 1x1 pixel background-colored JPEGs each crafted for the target platform (let's see: Win32, Win64, Mac OS X, Android, iOS, Linux 64 and we're done!). My point is that while Java applets are pretty holey at the moment, vulnerability to data received from a remote site is not unique to them.
> You're right, I have never written a huge application in C++
Ok, when you scale an application you get different concerns. The complexity does not increase linearly with size and with C++ it simply gets very very hard to write a large, correct, and reliable program - especially when multi-threading heavily and going cross-platform.
> it uses more memory than C++ with its garbage collection paradigm. Java enthusiasts always excuse this saying that you should get more memory or that newer computers will have more.
Java uses more memory for tiny programs due to the overhead of the virtual machine. Once the program is large (that is, a non-trivial application) then this overhead is negligible. Now C++ can allow you to do all sorts of neat but dodgy optimizations if you want but that is not conducive to reliable programs. Actually, with computers these days shipping with between 4 and 8 of RAM these days memory constraints are fairly rare unless you are programming in a very niiave way (eg. holding on to large buffers/images far longer than you need them). The real memory constraint for me is video RAM, and C++ overs no advantage over Java in this regard (and, due to the long development time, C++ is at a considerable disadvantage).
> it's slower than C++. In order for a Java program to run first the JVM has to be started and compile the bytecode. Granted, once it has run for a little, the JVM has found ways to optimise the bytecode into something that runs at more or less the same speed at C++, but there's still that initial penalty. Of course, the excuse every time someone mentions this is that recent updates to the JVM have added performance improvements. Yeah, we've seen those. They don't make much of a difference.
it requires a huge virtual machine that has to be ported to your platform. Updates are frequent, too, which gets me to the next point.
Again, this only matters if you are running tiny programs and the year is 2005. Ever since then the JVM is usually pre-loaded (just like other system libraries) or loaded on first use (depending on OS) and the start-up time is negligible. Now, as you admit, for large programs this is a non-issue, and for my large sim once the JIT compiler gets into it the speed-ups are fairly impressive (and I don't have to micro-optimize since the vastly more clever Sun engineers do it for me).
> it requires a huge virtual machine that has to be ported to your platform. Updates are frequent, too, which gets me to the next point.
You would prefer a stagnant platform that is outdated, or updated each decade (like C++) ? nb: GCJ (based on GCC/G++) may be a suitable Java implementation for you then, but OpenJDK performs considerably faster.
> it has bad backwards compatibility. Parts of the language get deprecated over time. Java applets made during the 90s often don't work any more.
Java's backward compatibility is vastly better than C++'s. Why? because C++ has so little functionality in its standard library it depends on external libraries to get much useful stuff done. These have mostly changed since the 90s which means that non-trivial C++ programs have to be recompiled every couple of years to work on new platforms. With Java the library is very stable (although there are some avoidable exceptions, eg. DataSource.getParentLogger() change between JDK 6 & 7), all of my very old Java programs still run without recompilation - mostly since I was used to writing cross-platform apps in C++ when I wrote them in Java so I avoided all the pitfalls that later generations of developers fall in to (those that have only ever known a Windows desktop, and believe the IT world will be like that forever).
> it's unintuitive. Want to compare strings? Use the equal method instead of the equal signs. Want to manipulate strings? Wait, use the StringBuilder! I'm aware that this is like this to keep Java 'clean', but I think operator overloading and easy string manipulation makes things easier. Besides, Java stopped being
> There was a time when applets were viewed as *the* reason to learn Java, and the platform was marketed on the power of applets. ... and that time was around 1998. It's been nearly a decade and a half since then. Personally, I prefer Java WebStart to applets. Yes, there is a problem with the Oracle's implementation of Java sandboxing - the concept was sound though (and how many other development environments have this concept?).
> With Java, you can exploit OS X, Linux, BSD, any...
I know you say "Java applets" later on, but it is important to qualify this at every stage (since even the techie Slashdot readers appear to be horribly ignorant that there are differences between JavaScript, Java applets and Java applications).
Readers should take note:
1) In general Java applications and web services are secure (in fact, more secure than C++ etc)
2) It is malicious Java applets that pose a potential risk to users (just like malicious buffer-overrun inducing JPEG images do).
Now cue the hundreds of Java-hating posts that don't know the difference between JavaScript, Java applets and Java applications/servlets but still think that some other technology is more secure (hint: it is not - every tech out there has holes that get discovered from time to time - including your operating system).
So you are saying your C# application is possibly insecure? since the article is about Java the parent's post stands: no one uses Java in modern apps - instead they use REST or SOAP webservices (much more secure - assuming you know what you are doing).
Ok, let me pose a simple question for you. Let's say you have some big objects in your program and you want to put them on the heap. Now, to get good performance out of your program you are going to make it thoroughly multi-threaded. Now, because the market is getting more and more diverse you want your program to run on Mac, Linux, Windows and Android. You don't have the resources of a global mega-corp to achieve this but still want to get the project done. Should I use C++ with its problems between compiler versions (ah, the joy of porting your C++ program between 0.1 releases of G++) let alone compilers, plus the effort of porting between operating systems, plus choosing which library to use (for multi-threading and synchronization [standardized in Java], GUI [standardized in Java], network I/O [standardized in Java], device input [cross-platform with JInput], audio [cross-platform with JOAL]). etc etc.
Have you ever built (or tried to build) such a cross-platform, high-performance, networked (multiplayer in my case), multi-input device program yourself? If you even attempted this (probably not, yeah?) was it a nice experience in C++?
Let me assume you have never actually done this yourself, that means you dare to accuse others of having drunk the "kool-aid" when perhaps they are the ones who have done such development 'in anger' and are trying to enlighten others into using far more modern tools and techniques. That's why when I hear such anti-Java nonsense from C++/C#/Python folks who have never even tried to proper *very large, portable and complex* apps I get cranky, since these folks simply have no idea about the reality of developing such applications in 2012 (where Java is, IMHO, the best tool to solve the problem when you consider business/financial/time-to-market factors in addition to technical ones).
C++, its tools and common techniques are fairly outdated. That doesn't make C++ useless (I still use it whenever I have to integrate hardware), but it hardly makes it the first or best choice for modern applications. Once you are able to write clean (Javabeans without cruft ftw!) and legible Java code that is performant (eg. when to use different parts of the Java library eg. String/StrungBuffer/StringBuilder; and including learning how to use JVisualVM included in the JDK) then you would never go back to C++ (like I said, I have two decades using C++ and I'm always dislike going back to it on the occasions I have to - everything about it and its tools are outdated).
So, I'd be interested to hear back from you if you have actually written a large, complex, multi-threaded and multi-platform program recently and found C++ the best tool for this purpose and why. Otherwise, admit to yourself that perhaps it is your perspective (as well as C++ itself) that is actually outdated.
> Carmack was talking about the financial viablity of targeting games to run on desktop Linux.
Remember, there is an enormous difference in targetting games to write on Linux *as well as other platforms*, compared to targetting games for Linux only (which would be a financial mistake). I'm currently using Java+JoGL(OpenGL+GLSL)+JOAL(OpenAL)+JInput to write a combat flight simulator. I develop on Mac and test on Linux and Windows. Because I have chosen these technologies the only cross-platform issues I have are slight peculiarties in the OpenGL driver implementations (AMD vs NVidia) on each platform - and these are pretty minor.
It would be expensive to include a Linux port if I was working in C++, and Carmack would be right about that. But since I'm using Java (which is very, very fast for my purposes - the bottleneck is GPU performance by far since all the large effort is done in shaders) having my program work on Java pretty much comes for free (and I used to do a lot of cross-platform C and C++ in the day, so I don't make the stupid platform-dependent mistakes that many other devs do ; eg. put in platform-dependent filepath separators rather than use File.separator, etc). Hence, I must disagree with Carmack's statement. A Linux port is not financially viable for him since he is using old outdated technology to build his software (that is, C++, which I have used for two decades, but am glad that OpenJDK/Oracle Java is now super fast and I don't have the PITA of C++ anymore; plus multi-core apps with *shared resources* are vastly easier to build [which means Java's multi-core performance destroys C++ single-core any day]).
So, while Carmack may be a genius when it comes to graphics algorithms using the technologies he has used for a long time, it turns out that in terms of "financial viability" Linux is perfectly possible provided you are willing to adapt to more modern tools.
Final note: the world is becoming increasingly more cross-platform, not less. So if you are using technologies that require effort to port between platforms you may be making a good technological choice but a poor 'business/financial' choice. Hence, I prefer Java to C/C++/C#(Mono doesn't count; the libraries are not the same as C# ones) etc for most of my work since 'porting' is so easy.
> There is no aspect, no facet, no moment of life that can't be improved with pizza.
As much as I love pizza, the "longevity" part of life is not usually correlated with increasing pizza. I'm sad about this, but it is true.
You are missing the point of my post. What I said was that you must reduce portion sizes to lose weight. No matter what you consume you cannot lose weight while having the portion sizes that are typical in the US (which, as a foreigner that often visits, always amazes me how vast they are - the power of your economy produces plenty at very cheap prices). This does not mean you will go hungry (people keep overeating because the fullness reaction takes 10-20 mins to kick in). In fact letting yourself get hungry is a bad idea, since it can lead to binging (I've seen supersized folks starve themselves all day and then crack and have a massive binge- hence they balloon further and their cycle continues).
Now the tiny amounts of carbs (ignoring all the simple carbs in beer) worked for you partially because you are sedentary. You cannot exercise without needing more carbs than your post suggests - I notice that about an hour after an hour run I start to get fuzzy in thinking (eg. coding!) and a glass of fruit juice helps bring my blood sugar up and I'm good to go (and I still lose mass despite the carbs in the juice). So, if you exercised as much as I do then you would probably also need more carbs; which requires a better balance of food (not just protein) and (only slightly) smaller portion sizes than people routinely consume.
Now clearly given your large mass losing weight was more important than anything else. This reduces your risk to a bunch of diseases. It is not likely to make you live any longer though (it only helps your heart a little). Only regular exercise helps with that. So a combination of lean body mass and exercise is required. I hope this motivates you to get out and walk:) Walking is one of the easiest and best exercises, which we modern folks tend to do very little off. I do notice how many US cities are not designed for walking at all, the whole layout is often designed solely for cars.
> Thanks for the link to LibreOffice, but LibreOffice is not MS-Word.
LibreOffice is indeed not MS-Word. LibreOffice is instead like MS-Office, but you can get the latest and greatest LibreOffice every month if you want - no waiting for procurement and IT to decide to roll out some version once in a while. LibreOffice's Writer is plainer (fewer nice looking themes) than MS-Word but the difference is Writer doesn't get in your way when you write stuff (I'm always wrestling with MS-Word to stopping 'Clippying' what I've just done). Writer also has *vastly* better output to PDF (which is what you want to deliver your stuff to customers in, yeah?), as I find MS-Word often borks the formatting of the source document every time I 'print' to PDF - complete madness!
Slashdot Mirror
> So what specifically makes Java more reliable?
A combination of factors, like Java always ensuring everything is initialized, like the garbage collector ensuring that resources shared between multiple threads are eventually cleaned up, or not cleaned up too soon, and by setting references to null (aiding the gc) you can avoid the dangling pointers you get in C++ (which gets horrifically difficult in complex multi-threading programs in C++). The other thing is that Java has certain practices and tools that are not so common in the C++ code I encounter from other people. Yes, it is perfectly possible to do Test Driven Development in C++, but I hardly ever see it done - whereas it is pretty pervasive in the Java community and there are a vast number of tools and reporting engines for Java that help you utilize such techniques. My favourite tool of all is JVisualVM which is similar to gprof but you can instanteously attach to any running program/JVM without having to specially recompile your program.
> Java becomes the better choice for new heavily multi-threaded stuff, IMHO.
Why is that?
Thanks for asking. The real problem is when you have heap-allocated resources in a multi-threaded environment. Who owns the shared resource and who is responsible for releasing it, and when? For stuff that you write yourself this is not such a problem (I'd guess most Slashdotters are better than average devs, yeah?), but when you use libraries (especially older ones) then this becomes problematic very quickly (if they have different memory management strategies to yours, eg using wrappers C libraries in your C++). Again, all these problems can be solved when building large, complex C++ applications but when using Java I never have to devote nearly as much brainpower to worrying about these concerns. Instead, I get to devote my effort to the problem domain (which in my case is not simple form-to-database apps but is in fact quite complex physics [eg. simulating the optical transmission of the atmosphere in real time etc]).
So, on Slashdot it seems very fashionable to 'dis' Java as not 'l337' enough (and hence crufty and outmoded C++ is considered more leet), but I find Java an excellent go-to language for a very wide range of problems (webapp using GWT, embedded, and even my rich-client flight simulator).
> I think Swing looks ugly, and doesn't blend in with the native OS
Many people I've made gaming utilities for rather like the Nimbus Look n' Feel (L&F). Perhaps your perception of Swing of the the rather ugly and outdated Metal L&F. I guess with most stuff moving to browser based apps its hard to find modern Swing apps, so it is easy to only think of Swing as the old apps you used to get.
> I think Swing looks ugly, and doesn't blend in with the native OS (not exactly the spirit of cross-platform), and I suspect that is the common opinion too.
That is a common but also rather out-of-date opinion. Most applications on Windows (for example) don't look like each other: MFC CTRL3D.DLL apps don't look like WinForms apps that don't look like browser apps that don't look like games (and their custom UIs) that don't look like MS Office not apps from the big providers (eg. HP printer driver control panel, or Adobe, or Symantec etc etc). In short, the lack of nativeness is a bit of a red herring. The problem with Swing apps was not really the Look, it was the Feel. Many developers made the mistake of blocking the Event Dispatch Thread (EDT) in Swing which made it feel like it was a slug and not responsive. When you don't do that (and make proper use of threading) then Swing apps generally are very performant and a delight to use (apart from a few quirks like not-quite-native looking file dialogs in the past; but those things have mostly been resolved now).
> Still, feel free to use it. If it's your strongest toolkit (ie. the one you know best), then it's the best toolkit for you to use. :) It turns out that Swing has excellent integration with JoGL so that mixing 2D and 3D components is a complete breeze (and I don't have to write my own midget library to do the 2D stuff, so I get to overlay all the standard Swing controls even in my 3D views - which is vastly better than most of the crappy interfaces people seem to write when they try and mix DirectX/Direct3D with 2D controls). Given the vast number of controls needed in a combat flight simulator it is very useful to be able to pop up dialogs so the users can adjust their axis mappings and commands (eg. flight controls, radar slew, trim functions, countermeasure, sensor pod aiming etc) while still in-game.
Thanks
The parent posted this:
>"I do not think any sensible developer would subject its users to the horrors of AWT or Swing"
personally I disagree and find Swing to be one of the most powerful and productive rich client toolkits out there. If you know what you are doing you can do just about anything (although Swing has plenty of flaws still). It was based on that parent comment that I decided to "defensively" elaborate why I consider Java suitable - and IMHO, particularly suitable for massive multi-threading in a multi-platform application (yes, you can do the same in C++, but it is very much a hassle and the libraries change on each target platform; which was part of my point). Hence, I still see Java as the premier choice of platform for my project (which is what the parent of my original post disputed - he could see no use for client side Java; in fact I don't see any economic alternative; C/C++/C#/Python etc are not nearly as suitable for my purposes and intended development timescale).
I considered Unity3d but it wasn't suitable for my particular purposes - and I would still have to code in C++ (which after two decades of use I'm well sick of it).
Sorry, QT is vile and unnatural, IMHO. Effective sure, but unnatural for those used to proper Object Oriented UI toolkits (eg. back in the day Borland's OWL, Swing etc).
The C++ code itself is nothing. What matters is that for each platform you target you need different libraries, and each library has its own idiom. Then you end up contorting your architecture for each set of libraries you are trying to integrate. This is not impossible (I've written lots of portable, complex C++ in the last two decades) but I can tell you it is *vastly* easier, more consistent, and I would argue more performant (since the time I save not fixing dumb C++ loopholes I instead spent optimizing my Java) to use Java.
Flightgear is an admirable bit of software. I looked at extending it but realized after two decades of C++ and a decade of Java I knew which language to base a new *reliable* multi-player, multi-core product on.
So I understand your advocacy for C++. You can certainly accomplish useful stuff in it (and I have). However, I would never start a new forward-looking project in it. Java becomes the better choice for new heavily multi-threaded stuff, IMHO. (and yes, that includes rich clients, which can me made to look amazing using the "Filthy Rich Client" Swing techniques and OpenGL/JoGL).
What would you like to know, specifically? Note that the 2D UI is a minor part of the application, and a "Filthy Rich Client" (Google if you don't understand this term) Swing startup is perfectly fine to start the JoGL/OpenGL main UI.
> Because it sounds a bit ... exaggerated.
This is why I am taking to point out that Java is more than adequate for 3D gaming (since all the important stuff runs on the GPU anyway). I find it lamentable that Slashdotters are so anti-Java (and have out of date perspectives) they simply cannot comprehend that modern JVMs are not only as good as C++ for gaming, they are superior in my experience as a indie game developer (for a hard-core simulation; eg. multi-threaded resource sharing in Java is so much easier than in C++ when you are targetting multiple-platforms). I understand that existing game devs with existing C++ pipelines and assets aren't interested in Java, but new games development should seriously consider it - expecially if you want to be as massively profitable as Java games like Minecraft are.
What do you get for a similar search of "Windows"? (that is also another "platform", just as the JVM is). My point is not that Java is without vulnerabilities - clearly it has them - but that calling it "malware" is misleading since anything with a similar large amount of functionality also has a lot of attack surface. So the hyperbole ought to be cut. k?
Ummm, because it is the best cross-platform solution for rich clients out there. If there was something better I would use it, but there isn't (I'm writing a jet combat flight simulator and C++ and C# simply are too much effort to make truly cross-platform; eg. Mac, Linux, Window, Android). If you would please suggest a useful alternative to Java that was cross-platform and I didn't have to go through all the awful porting nonsense of C++ or C#/Mono (been there done that, don't want to do it again) for my flight sim then I'm all ears.
Java is malware now? Talk about flamebait from an AC. If Java is malware then so it MSVCRT and Internet Explorer. Talk about hyperbole!
Try a Thrustmaster Warthog HOTAS (Google if it you don't know what it is), TrackIR 5 headtracker, Thrustmaster MFDs, Saitek Rudder pedals, triple 1080p monitors, several Lilliput touch screens and the usual keyboard and mouse. Yes, not everyone's rig is like this, but mine is. This is not meant as bragging, but just a statement that PC gaming is not just keyboard and mouse - even if the vast majority of it is. There are people that are gaming in ways that only a PC can.
This gives me an experience that no console can match.Plus, the console games both have less diversity and less community modding (which can be very creative). Consoles are wonderful for a quick fix of gaming and the low hassle. For more sophisticated games and gamers the PC is a far better choice (eg. I love full-fidelity combat flight sims and Arma 2, there is nothing like these on consoles since the hardware can't hack-it and the console gamers' tastes are not generally as varied as PC gamers, again IMHO).
> I don't have to believe anything you say.
No you don't. But what you could do are check facts instead. Either build a modern program (eg. game) in Java yourself (doesn't have to be big, just a little one - and profile with JVisualVM) or look around on the web for *current* statements that prove or disprove my assertions. I don't expect you to believe my statements based soley on my assertions - I'm confident that if you actually took the time to check you would come to the same conclusions I have: the areas where Java used to be weak and C++ was strong have pretty much disappeared, therefore new development in C++ is unnecessary for the vast majority of developers, therefore C++ is outdated (compared to more modern tools and techniques; this was my original assertion).
> That's exactly the excuse I was talking about. You have no business using loads of RAM for your application. You should use as little as possible to run on as many computers as possible and allow as many other programs to run as possible (instead of just today's). You're not the only program on the computer, after all, and I'm not going to buy a new computer to run your program.
Wrong. Memory is there to be used. In the case of a game it would be negligent not to efficiently use all the resources that were available. In the case of a general application the application should play nicely with others. In my experience even small Java applications do not have a memory footprint that is excessively larger than other complex applications. For system tools you could argue differently but in fact I have created lots of little Java applications for myself in the nature of Unix tools and memory use has never been an issue. Your view is outdated (just like C++ application development).
> You're not the only program on the computer, after all, and I'm not going to buy a new computer to run your program.
Wrong. You don't know the market I'm aiming for at all. In fact, combat flight simmers are not running their sims on their iPhones or tablets. Even consoles are too weak for proper simulation. These simmers often upgrade their machines (or the major parts) every two years. So you see, I'm not aiming for the lowest-common-denominator market as your incorrectly suppose, it is completely uneconomic (not to mention uninteresting) to support low end machines (eg. puny integrated graphics). Once nice thing I will say is that my program runs very very smoothly (so easy to massively multi-thread in Java while sharing resources) and much more reliably on the same hardware than the DCS:Word simulator (you're probably totally unaware about this simulator, which is the current market leader). Unfortunately DCS:World is still in beta stage, but has quite a few bugs (it's written in C++) that cause crash-to-desktop that I simply don't have to worry about in Java (one of the reasons Java was invented). Given DCS:World's predecessors (and C++ games and development practices in general) I think that this will never be fully resolved (again, another reason motivating me to choose Java over C++).
> I neglected to mention how the garbage collector will only clean up when it feels like it and slow down your program. This makes it unsuitable for time-critical programs like video games.
Wrong. There are lots of garbage collectors to choose from. You can get deterministic garbage collection with real time Java. However, I've found the G1 and parallel collectors to be sufficient for my needs (using less than 1% of CPU every 5 seconds or so - as shown by JVisualVM which comes with the JDK; it's like g++'s gprof but much much better). So, here I am, a game developer and you are telling me that the current Java garbage collectors are unsuitable for games? looks like you don't know what you are talking about (I'm starting to get a theme here) since you appear to be basing your statements on outdated information.
Also, people used to blame Java or the garbage collector when there were pauses in Java GUI programs. This occurred when bad developers blocked the Event Dispatch Thread (something competent Java developers are trained/know not to do). This is wrong and borne of ignorance. There is no fundamental problem with latency in Java (well, not worse than the other latencies in your system, like the millisecond-increases in latency in the O/S scheduler when I/O is happening etc).
> The same excuse was used in 2005 with a different previous year. And if Java is so great it should be good for tiny programs, too.
Wrong. I have created small commercial Java programs to run embedded systems on single board computers. Initially I used gcj but it turns out the Sun JDK was fine for this use. The result was tiny (even if using very complex logic). You can do ti
Applets are legacy. I agree with you, WebStart is a vastly better solution (plus, I've noticed that when I converted a heavily-used applet I had written to WebStart it ran around an order of magnitude faster; the browser plugin for applets is relatively slow).
> A malformed JPEG may successfully execute shellcode on one broken image decoder/renderer, simply crash another, and be caught and thrown out by a third. Which thing happens to any given client (visitor to the page hosting it) will depend on the client's software environment: their browser, their OS, whether they use 32-bit or 64-bit, etc. If you want to make it cross-platform, you'll need to not only have an exploit that works on multiple image libraries (or a suite of exploits that together cover all libraries, and some way to tell which one to use), you'll need shellcode that executes on all those platforms (and shellcoding is hard, especially in the face of the exploit mitigations found in most modern OSes).
JPG, or PDF, or PNG, or Flash, or ActiveX, or Javascript or browser or TCP stack implementation ... etc vulnerabilities are pretty common. Yes, you have to do more work than put up a single malicious applet, but it is not that much harder to put up half-a-dozen 1x1 pixel background-colored JPEGs each crafted for the target platform (let's see: Win32, Win64, Mac OS X, Android, iOS, Linux 64 and we're done!). My point is that while Java applets are pretty holey at the moment, vulnerability to data received from a remote site is not unique to them.
> How many malicious buffer-overrun JPEG images are there? I haven't see one in 5 years.
You haven't been looking?
> You're right, I have never written a huge application in C++
Ok, when you scale an application you get different concerns. The complexity does not increase linearly with size and with C++ it simply gets very very hard to write a large, correct, and reliable program - especially when multi-threading heavily and going cross-platform.
> it uses more memory than C++ with its garbage collection paradigm. Java enthusiasts always excuse this saying that you should get more memory or that newer computers will have more.
Java uses more memory for tiny programs due to the overhead of the virtual machine. Once the program is large (that is, a non-trivial application) then this overhead is negligible. Now C++ can allow you to do all sorts of neat but dodgy optimizations if you want but that is not conducive to reliable programs. Actually, with computers these days shipping with between 4 and 8 of RAM these days memory constraints are fairly rare unless you are programming in a very niiave way (eg. holding on to large buffers/images far longer than you need them). The real memory constraint for me is video RAM, and C++ overs no advantage over Java in this regard (and, due to the long development time, C++ is at a considerable disadvantage).
> it's slower than C++. In order for a Java program to run first the JVM has to be started and compile the bytecode. Granted, once it has run for a little, the JVM has found ways to optimise the bytecode into something that runs at more or less the same speed at C++, but there's still that initial penalty. Of course, the excuse every time someone mentions this is that recent updates to the JVM have added performance improvements. Yeah, we've seen those. They don't make much of a difference. it requires a huge virtual machine that has to be ported to your platform. Updates are frequent, too, which gets me to the next point.
Again, this only matters if you are running tiny programs and the year is 2005. Ever since then the JVM is usually pre-loaded (just like other system libraries) or loaded on first use (depending on OS) and the start-up time is negligible. Now, as you admit, for large programs this is a non-issue, and for my large sim once the JIT compiler gets into it the speed-ups are fairly impressive (and I don't have to micro-optimize since the vastly more clever Sun engineers do it for me).
> it requires a huge virtual machine that has to be ported to your platform. Updates are frequent, too, which gets me to the next point.
You would prefer a stagnant platform that is outdated, or updated each decade (like C++) ? nb: GCJ (based on GCC/G++) may be a suitable Java implementation for you then, but OpenJDK performs considerably faster.
> it has bad backwards compatibility. Parts of the language get deprecated over time. Java applets made during the 90s often don't work any more.
Java's backward compatibility is vastly better than C++'s. Why? because C++ has so little functionality in its standard library it depends on external libraries to get much useful stuff done. These have mostly changed since the 90s which means that non-trivial C++ programs have to be recompiled every couple of years to work on new platforms. With Java the library is very stable (although there are some avoidable exceptions, eg. DataSource.getParentLogger() change between JDK 6 & 7), all of my very old Java programs still run without recompilation - mostly since I was used to writing cross-platform apps in C++ when I wrote them in Java so I avoided all the pitfalls that later generations of developers fall in to (those that have only ever known a Windows desktop, and believe the IT world will be like that forever).
> it's unintuitive. Want to compare strings? Use the equal method instead of the equal signs. Want to manipulate strings? Wait, use the StringBuilder! I'm aware that this is like this to keep Java 'clean', but I think operator overloading and easy string manipulation makes things easier. Besides, Java stopped being
> There was a time when applets were viewed as *the* reason to learn Java, and the platform was marketed on the power of applets.
... and that time was around 1998. It's been nearly a decade and a half since then. Personally, I prefer Java WebStart to applets. Yes, there is a problem with the Oracle's implementation of Java sandboxing - the concept was sound though (and how many other development environments have this concept?).
> With Java, you can exploit OS X, Linux, BSD, any ...
I know you say "Java applets" later on, but it is important to qualify this at every stage (since even the techie Slashdot readers appear to be horribly ignorant that there are differences between JavaScript, Java applets and Java applications).
Readers should take note:
Now cue the hundreds of Java-hating posts that don't know the difference between JavaScript, Java applets and Java applications/servlets but still think that some other technology is more secure (hint: it is not - every tech out there has holes that get discovered from time to time - including your operating system).
Yes, but you can also attack through images (eg. the various JPEG attacks) and JavaScript. Should these be universally banned too?
So you are saying your C# application is possibly insecure? since the article is about Java the parent's post stands: no one uses Java in modern apps - instead they use REST or SOAP webservices (much more secure - assuming you know what you are doing).
Ok, let me pose a simple question for you. Let's say you have some big objects in your program and you want to put them on the heap. Now, to get good performance out of your program you are going to make it thoroughly multi-threaded. Now, because the market is getting more and more diverse you want your program to run on Mac, Linux, Windows and Android. You don't have the resources of a global mega-corp to achieve this but still want to get the project done. Should I use C++ with its problems between compiler versions (ah, the joy of porting your C++ program between 0.1 releases of G++) let alone compilers, plus the effort of porting between operating systems, plus choosing which library to use (for multi-threading and synchronization [standardized in Java], GUI [standardized in Java], network I/O [standardized in Java], device input [cross-platform with JInput], audio [cross-platform with JOAL]). etc etc.
Have you ever built (or tried to build) such a cross-platform, high-performance, networked (multiplayer in my case), multi-input device program yourself? If you even attempted this (probably not, yeah?) was it a nice experience in C++?
Let me assume you have never actually done this yourself, that means you dare to accuse others of having drunk the "kool-aid" when perhaps they are the ones who have done such development 'in anger' and are trying to enlighten others into using far more modern tools and techniques. That's why when I hear such anti-Java nonsense from C++/C#/Python folks who have never even tried to proper *very large, portable and complex* apps I get cranky, since these folks simply have no idea about the reality of developing such applications in 2012 (where Java is, IMHO, the best tool to solve the problem when you consider business/financial/time-to-market factors in addition to technical ones).
C++, its tools and common techniques are fairly outdated. That doesn't make C++ useless (I still use it whenever I have to integrate hardware), but it hardly makes it the first or best choice for modern applications. Once you are able to write clean (Javabeans without cruft ftw!) and legible Java code that is performant (eg. when to use different parts of the Java library eg. String/StrungBuffer/StringBuilder; and including learning how to use JVisualVM included in the JDK) then you would never go back to C++ (like I said, I have two decades using C++ and I'm always dislike going back to it on the occasions I have to - everything about it and its tools are outdated).
So, I'd be interested to hear back from you if you have actually written a large, complex, multi-threaded and multi-platform program recently and found C++ the best tool for this purpose and why. Otherwise, admit to yourself that perhaps it is your perspective (as well as C++ itself) that is actually outdated.
> Carmack was talking about the financial viablity of targeting games to run on desktop Linux.
Remember, there is an enormous difference in targetting games to write on Linux *as well as other platforms*, compared to targetting games for Linux only (which would be a financial mistake). I'm currently using Java+JoGL(OpenGL+GLSL)+JOAL(OpenAL)+JInput to write a combat flight simulator. I develop on Mac and test on Linux and Windows. Because I have chosen these technologies the only cross-platform issues I have are slight peculiarties in the OpenGL driver implementations (AMD vs NVidia) on each platform - and these are pretty minor.
It would be expensive to include a Linux port if I was working in C++, and Carmack would be right about that. But since I'm using Java (which is very, very fast for my purposes - the bottleneck is GPU performance by far since all the large effort is done in shaders) having my program work on Java pretty much comes for free (and I used to do a lot of cross-platform C and C++ in the day, so I don't make the stupid platform-dependent mistakes that many other devs do ; eg. put in platform-dependent filepath separators rather than use File.separator, etc). Hence, I must disagree with Carmack's statement. A Linux port is not financially viable for him since he is using old outdated technology to build his software (that is, C++, which I have used for two decades, but am glad that OpenJDK/Oracle Java is now super fast and I don't have the PITA of C++ anymore; plus multi-core apps with *shared resources* are vastly easier to build [which means Java's multi-core performance destroys C++ single-core any day]).
So, while Carmack may be a genius when it comes to graphics algorithms using the technologies he has used for a long time, it turns out that in terms of "financial viability" Linux is perfectly possible provided you are willing to adapt to more modern tools.
Final note: the world is becoming increasingly more cross-platform, not less. So if you are using technologies that require effort to port between platforms you may be making a good technological choice but a poor 'business/financial' choice. Hence, I prefer Java to C/C++/C#(Mono doesn't count; the libraries are not the same as C# ones) etc for most of my work since 'porting' is so easy.
> There is no aspect, no facet, no moment of life that can't be improved with pizza.
As much as I love pizza, the "longevity" part of life is not usually correlated with increasing pizza. I'm sad about this, but it is true.
That's excellent you lost so much weight.
You are missing the point of my post. What I said was that you must reduce portion sizes to lose weight. No matter what you consume you cannot lose weight while having the portion sizes that are typical in the US (which, as a foreigner that often visits, always amazes me how vast they are - the power of your economy produces plenty at very cheap prices). This does not mean you will go hungry (people keep overeating because the fullness reaction takes 10-20 mins to kick in). In fact letting yourself get hungry is a bad idea, since it can lead to binging (I've seen supersized folks starve themselves all day and then crack and have a massive binge- hence they balloon further and their cycle continues).
Now the tiny amounts of carbs (ignoring all the simple carbs in beer) worked for you partially because you are sedentary. You cannot exercise without needing more carbs than your post suggests - I notice that about an hour after an hour run I start to get fuzzy in thinking (eg. coding!) and a glass of fruit juice helps bring my blood sugar up and I'm good to go (and I still lose mass despite the carbs in the juice). So, if you exercised as much as I do then you would probably also need more carbs; which requires a better balance of food (not just protein) and (only slightly) smaller portion sizes than people routinely consume.
Now clearly given your large mass losing weight was more important than anything else. This reduces your risk to a bunch of diseases. It is not likely to make you live any longer though (it only helps your heart a little). Only regular exercise helps with that. So a combination of lean body mass and exercise is required. I hope this motivates you to get out and walk :) Walking is one of the easiest and best exercises, which we modern folks tend to do very little off. I do notice how many US cities are not designed for walking at all, the whole layout is often designed solely for cars.
> Thanks for the link to LibreOffice, but LibreOffice is not MS-Word.
LibreOffice is indeed not MS-Word. LibreOffice is instead like MS-Office, but you can get the latest and greatest LibreOffice every month if you want - no waiting for procurement and IT to decide to roll out some version once in a while. LibreOffice's Writer is plainer (fewer nice looking themes) than MS-Word but the difference is Writer doesn't get in your way when you write stuff (I'm always wrestling with MS-Word to stopping 'Clippying' what I've just done). Writer also has *vastly* better output to PDF (which is what you want to deliver your stuff to customers in, yeah?), as I find MS-Word often borks the formatting of the source document every time I 'print' to PDF - complete madness!