Eclipse wasn’t built to do C++ development. Of course support has been built in, but its a bit too basic. Netbeans has the same problem there.
Comparable to Visual C++ is Code::Blocks
Its built on top of GNU tools, Mingw32 on Windows platforms. Its a bit fiddly to setup a project structure perhaps, but that’s to be attributed to the language really 
Java is a good progamming language to make games. like the first post, most games are breathtaking for their graphics and design. Java game developers aren’t that skilled in graphics all the time. Java is a good programming language to develop games, I mean look at runescape and minecraft, even though they used external libraries, it shows that java is still a good programming language to use. It just takes hard word, that’s all it needs.
They shouldn’t have to be, that’s the comfort zone of graphics designers.
Nobody is knocking the programming language here, the main beef is with the Java runtime and its unfriendliness towards end-users and its difficulty of deployment I’ve been playing around myself a bit with bundling a runtime with an application (according to my wishes of making it as simple as running a native application); through some efforts I’ve actually managed to create a little configurable tool that can strip down a JRE in several ways; I’ve tested it on a Java 6 64 bits JRE and I could take it down from ~100mb to ~28mb, about 14mb when 7-zipped. Not bad!
The only problem with that is that I have to yank out far more than Oracle allows in the rules for runtime bundling, so its no good for commercial stuff 
The biggest contributor to the size is not the binaries but the rt.jar; for game development purposes I strip out everything that you don’t need in a game which includes anything related to XML, JNDI, corba, JDBC, etc. etc. Hopefully, Java 8 with its modularized approach will make that easier to do and at the same time legal to distribute.
What’s the main problem with a large download? The datatraffic of the download time for players?
If it’s the download time, then all I can say is that your typicial game demo is about 100MB-1GB, dwarfing the LZMA-ed JRE size. Further, average Joe seems to think that a 5MB game simply can’t be any good, so even in that way providing a big download is almost an advantage.
If it’s datatraffic, well, it’s cheaper than you think (about 0.05$/GB max) if you are willing to throw about $50/month at it. It’s easy to scale, and if all else fails, use a free-ish CDN, like MegaUpload (ahem…).
The old issues of JRE size are simply… irrelevant these days. Times changed. Only an engineer’s fascination with unnecessary optimisation causes us to try and “solve” the problem.
Cas
Agreed and with Project Jigsaw being part of Java 8, the core JRE without modules is about 10mb-15mb uncompressed! So yeh JRE size is very much irrelevant these days.
Also consider how much bandwidth is used by your average users these days, typically just the front page of popular websites can be 1mb+ (e.g. a twitter page is about 3mb). Streaming video or watching HD Youtube video has also become common and you can use well over a 100mb of bandwidth without a sweat.
That’s awesome!
My reasons are simple: I create small games, I want to offer a small download package 
Of all the things I wanted to achieve this was the simplest so I started with it. That becomes increasingly more useful when you want to deliver MANY small games, but then I’d start to think about delivering them in one package. I only spent a few hours on it, don’t think I would spend weeks trying to engineer something that is ultimately not so useful in the general cases. I have left the premature optimization phase behind me a looooooong time ago. The more interesting aspect of runtime bundling is that of cross-platform bootstrapping, and that’s what I’m taking my time with right now.
Funny discussion anyway, I tend to say the same to people who start to hyperventilate when a program uses more than 1% of their 3GB+ memory. I tend to have to explain that it is the same as having a shed built in your yard and then keeping it empty because you don’t like the clutter.
Eclipse/Netbeans are the main reason for me to stay with Java. BUT, there is a lot of enjoyment to just go back to a simple text editor (like Notepad++) and do some JS or AS3. Flashdevelop is nice to work with as well.
Just like a good and solid human relationship needs absence to work, programmers should leave the security of their home language/IDE to fully appreciate it
WRT: JDK size. It’s also about perception. Let’s say I had an open source library that performed some small task that you need done. You grab my precompiled jar and it’s a few hundred megabytes. The bulk size of the library will most likely make you predisposed to ignore the implementation. Hey it’s big. Big means code bloat. Code bloat means slow and badly written…move on to the next possible solution. Now my implementation of the desired task might only be a tiny part of the whole library…but that would likely get lost in the noise.
Having a legal means of distributing small footprint runtimes would very much help with perception.
(EDIT: I’m talking about as an embedded scripting language here BTW)
Well put; I suffer from that same perception myself I must admit. I do Java web dev also using JSF among other tools and I was using Richfaces for a long time to add easy web 2.0 crud to it. But Richfaces 4.X is already minimally about 8-10mb of libraries that needs to be deployed on top of all the rest; a web app with a bit of muscle in it (ORM for example) can easily grow to 30mb only in dependencies and then you’re ready to write some code. So I dropped Richfaces in favor of Icefaces, which is under a megabyte and does basically the same, a little less perhaps but it fulfills all my needs. Part of that is because it is a lot less bloated.
I don’t know what it is. I just like things to be compact to have faith in it. Seeing how people moan about memory usage and how earth shattering it is when the executable size of utorrent grows above a megabyte (as a truthful example that I can remember), I’m pretty sure lots of people suffer from the same condition.
I was under the impression that this topic was about game deployment, not library deployment. I really don’t see the problem of adding 30mb of jars to a game… If you ditch a well proven lib solely because it’s too big for your game-download, then you’re making an odd decision, IMHO.
As per usual, the topic has wandered around in all kinds of directions.
Wasn’t the original question about Java’s perceived lack of success in penetration the game’s market? While at the same time there is a perceived success of languages like LUA. The reality doesn’t really matter.
But not necessarily if there is an alternative which is far less bloated, is just as proven and provides the same basic features. Blegh, its all personal preference anyway, discussing it is basically useless. My apologies for adding noise.
That’s indeed a poor argument: if everything is equal except the size, then yes, you’d pick the smallest. We were discussing dropping libraries solely because of their size. As long as you stay under 100mb or so, typical gamers couldn’t care less.
I think the problem is deployment - this is the area I dread when it comes to getting my app ‘out there’. Deployment is the only special consideration for a Java game - after the game is installed the user couldn’t care less what language it was coded in. 10 to 1 they don’t even know what Java is, and if they have heard of it they probably think it is JavaScript!
I have done some development of NetBeans modules and Eclipse plugins and these offer a simple way to drag and drop Java code into a deployment environment. If there was traction in the community, we could use the Eclipse OSGI platform to build a game deployer. There would only need to be a single deployment of the game framework (which can update itself) and then deploying a game is as simple as copying the bundle to the right directory.
If I ever hop on the OSGi bandwagon again, I might take a shot at bundlifying LWJGL. It would certainly handle the problem of natives nicely, just toss a Bundle-NativeCode header in the manifest and boom, done.
Unfortunately, something tells me you won’t get a whole lot of traction in general getting game devs to write OSGi bundles :-\
I really don’t see what the problem is here NSIS. Installer. Private JRE. Small launchy executable or even a batch file. Windows done. Mac and Linux almost trivial.
Cas
Yep, OSGi is more useful for distributing frameworks, where every customer is potentially a snowflake with a unique configuration of the platform, needing multiple simultaneous versions of whatever libraries. Calling it overkill for a client-side game installation is an understatement.
Needing a private JRE is an embarassment. Hopefully Jigsaw helps with that.
Goodness no, a private JRE is the best thing ever. It becomes a “known quantity” when supporting things, and you get to choose exactly which JDK you want to code to as well.
Cas
whats the current state of jigsaw anyway ?