Which is a comparison only applicable to Microsoft platforms, so my my point stands, modulo  s/Java VM/MS .NET VM/.

Like it or not, the Mono VM runs infinitely faster on platforms to which no Java VM is available.

As much as I like Java and the Java ecosystem, if any of the widely portable Mono based systems (Unity, or, preferably, MonoGame) fully supported development on Linux, I'd almost certainly already have switched.

I'd be just as happy if inexpensive, non-kludgy methods existed to get decent Java access to all the applicable devices, of course. Dalvic on Android meets that threshold right now, but just *barely*, and the lack of direct Java 7 support is beginning to rankle.

I very much prefer NetBeans myself. 7.3 was a particularly nice release, though a few bugs I reported that happen to annoy me in my personal use have been fixed post release, so I've been running dev for a few weeks here. It's actually been very, very stable, so I doubt I'm going to switch back to the normal release any time soon.

I only have two real complaints about NetBeans right now.

First, it's Git integration is just slightly inferior to Eclipse's egit. Not a huge issue, since I do most of my git interaction at the command line anyway, but there are a few more things that egit supports than NetBeans. I will say, though, that I mostly prefer NetBeans' Git integration WRT the features that *are* there.

Second, and far and away most important, is the Android support. NBAndroid is actually quite serviceable for straight ahead Android development (i.e. using the standard APIs). However, trying to use it with libraries that have native components (like libgdx) has been a PITA. I'm on vacation this week, so I'm going to try to find time to make another run at it, but my last attempt was painful and messy enough that I'll just go ahead and call it a failure.

I was in quite a hurry when I tried it, though, and the experience in Eclipse and Idea was so smooth that I might have just been to impatient to get it right off.

Speaking of Idea, I own a license, and it's pretty darn slick for Java and Android development. If it had C & C++ support at least as good as CDT (or better, as good as NetBeans), I'd probably switch & not look back.

Well now, that would have been ideal, obviously, but that wasn't my point.

Alan_w had said "Now if Apple and Oracle could get together and have updates released before blocking the old version everything would be peachy.", and I was simply pointing out that his wish was nonsensical.

As much as it pains me to see Java with yet another black eye, Apple was right to block applets by default until Oracle could get their act together (assuming they have this time).

That's hilarious; I hadn't seen that graphic before.

I plead " not guilty", though' your honor.

The splash call-out at the top of the graphic says "... points to what is clearly obvious to everyone else".

Judging from comments here and elsewhere on the web, the situation *isn't* obvious to quite a few people.

If Oracle had the patch ready before there was a need to block the plug-in, there wouldn't have been ab exploit in the first place.

If there are no gotchas (and I can't think of any right off), that would certainly be a heck of a lot simpler, and much less brittle.

Not that I'm telling you anything you're not already *more* than versed in, but there is the niggling matter of whether a symlink to rt.jar in another directory meets Oracle's redistribution requirements.

I would think so, especially given the direction they're taking in Java 8 and with JavaFX 2, but with lawyers, you never know.

I found a little time tonight to look at this further.

After getting a fresh Ubuntu 64 bit install set up in a VM, I extracted the 32bit jre1.7.0_11 in ~/Downloads.

I was eventually able to get a hello world program to run w/o issues with the following setup:

Created ~/Downloads/jre1.7.0_11/bin/lib32, containing:

ld-2.15.so
ld-linux.so.2 (symlink to ld-2.15.so)
libc-2.15.so
libc.so.6 (symlink to libc-2.15.so)
libdl-2.15.so
libdl.so.2 (symlink to libdl-2.15.so)
libm-2.15.so
libm.so.6 (symlink to libm-2.15.so)
libpthread-2.15.so
libpthread.so.0 (symlink to libpthread-2.15.so)

I had placed Hello.jar up in ~/Downloads.

Then, sitting in ~/Downloads, I was able to run a simple hello world via:

LD_LIBRARY_PATH=jre1.7.0_11/bin/lib32 jre1.7.0_11/bin/lib32/ld-linux.so.2 jre1.7.0_11/bin/java -cp Hello.jar com.hexomancy.Hello

I was unable to get it to work properly with lib32 sitting anywhere else but in $JRE_DIR/bin, though it's not occurring to me just now why that might be. I've got a doozy of a week coming up, but perhaps I'll find time to look into it further.

A more complex executable would require additional libs in lib32, of course. Some of the libs in question are likely GPL, with the minor PITA that distributing GPL libs entails.

Also, since the whole set is, as I mentioned, not small, you'd probably want to figure out just what you need. The list in my previous response would be a start, and the rest could be found via some combination of ltrace and just running to see what the loader complains about.

Hope some of this is helpful!

More than what I'd call a "bunch of files".  /usr/lib/i366-linux-gnu on this machine is 203M. Of course, that includes some things that java doesn't need.

A quick check shows that java needs at least:

libpthread.so.0
libc.so.6
libdl.so.2

However, there are plenty of libs that are potentially pulled in later by the jre via dlopen() (in lib/i386), so if anything you're using in java requires one or more of them, you'll need those, as well.

I downloaded lwjgl-2.8.5 for a quick peek there, and it adds (again, not including anything pulled in via dlopen()):

libX11.so.6
libXext.so.6
libXcursor.so.1
libXrandr.so.2
libxcb.so.1
libXrender.so.1
libXfixes.so.3
libXau.so.6
libXdmcp.so.6
librt.so.1
libm.so.6

I don't have time right now to look further, I need to leave the house shortly - perhaps later tonight or tomorrow I can dig a bit deeper. Do you have a particular program that you want to have working? Or is it giving you SIGSEGV on even "java -version"?

To get more info on the fault, you could run via gdb. Even without debug symbols, you'd at least get a stack trace that way, which might point toward the problem.

eg:

gdb ./bin/java
(gdb) run -version

replace "-version" with whatever you need -- "-jar agame.jar" or whatever.

I'll at least check in this evening my time (CST - I'm in Minnesota, USA).

I assume your evil plan is to put together a tarball style install package that will run on either 32bit or 64bit machines w/o extra deps, in an attempt to make a tarball install as easy to use as a .deb or .rpm, yes?

If you export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH in a launch script, it should work.

There are other ways to manipulate the library search path, as well, but, if you're already using a launch script, this is probably the simplest thing to try.

I see the smiley, but it's still hard to tell - was that "ha, ha ... only serious", or were you just baiting?

Thanks for fixing that!

I've been lurking for ages, finally wanted to register and found the captcha broken ... 

All good now.