Does Java support OpenGL by itself?

Question

Note: This is long but I explaining everything that you need to know. Don't read half way through it and say "What's the question?". It's simple but long and I need help as soon as possible.

So I asked a question not long ago that was similar but it wasn't my best work. What I'm trying to do is make a small jar with no other files but the jar (maybe natives if needed) that handles a window and graphics for games. I'm making this for some people I know who don't want to get into advanced graphics and stuff to make games, plus I figure it would be easier to stick everything they need into one jar that they know how to use. Anyway I found JOGL but after like the past 3 hours or so all I got with JOGL was the memory to never use it because it's a pain to install (at least for me) and everyone says a different way to install it and I need like 100 files along with my jar to get it to work. So since I'm not dealing with JOGL i figured that it's best to try and find something else. So does anyway know any way to get OpenGL into java without libraries that add more files and if so just like 1 file? I'm trying to get it so it's just that jar and nothing else. I just want this done but I'm very confused. I would also like it to be able to run on Windows, Linux and Mac. I only have a Windows machine although I can get Linux to test it on and I know someone who has a Mac but keep in mind I'm building it on a Windows machine. So my question really is how would I be able to stick OpenGL (I would like OpenAL and maybe OpenCL too) in a single jar and nothing else? I have a few exceptions such as I'm kinda ok if I need a few natives but I don't want 10 jars and 50 natives and I need it to work on all kind of machines, and also I would like to be able to use swing to handle the window.

Answer 1

No, OpenGL is a library written in C. You will need some binary file for each platform to interface correctly with OpenGL. There has to be some platform specific part because the JavaVM does not virtualize the OpenGL device for you.

However when developing with Java you can use Maven which is a sort of advanced build system, like Ant but done right I heard people call it (I never used Ant though). You can just pull JOGL into Maven and it will use the correct binaries for each platform when building or releasing.

Here are the entries in the POM file I use to use JOGL with Maven:

<repositories>
     <repository>
        <id>jogamp-remote</id>
        <name>jogamp test mirror</name>
        <url>http://www.jogamp.org/deployment/maven/</url>
        <layout>default</layout>
      </repository>
  </repositories>

 <dependency>
     <groupId>org.jogamp.gluegen</groupId>
     <artifactId>gluegen-rt-main</artifactId>
     <version>2.0-rc9</version>
   </dependency>

   <dependency>
     <groupId>org.jogamp.jogl</groupId>
     <artifactId>jogl-all-main</artifactId>
     <version>2.0-rc9</version>
   </dependency>       

(Note: I totally feel your pain when using JOGL without an automated system to do it for you, men their documentation is worthless I usually end up just placing all the natives in the same file as the JAR and hoping it works)

Answer 2

An alternative to JOGL is LWJGL. It really is "lightweight", as the name suggests, both in terms of installation and in terms of provided functionality - it's a pure wrapper to the C functions, with some additional (and really helpful) checkers.

The documentation is certainly sufficient for me to install it on Windows, Linux and Mac; however, while 32-bit Windows is basically straightforward, adding 64-bit Java on Windows is a bit more of a hassle. And Linux is, as always, a bit harder for it's own reasons.

I'm not sure if you can into one single .jar and run it on any platform; however it's possible to make a single download that would work anywhere.

Answer 3

I'm adding this by way of expansion on a comment I made to a previous answer. This question in itself shows a fundamental misunderstanding of what OpenGL is so I believe it's necessary to say more.

OpenGL is not software

OpenGL is "a software interface to graphics hardware" (page 1 of the OpenGL specification until the ARB changed the terminology a little recently). From this you may glean some important things:

• The graphics hardware is what actually does all the work; all that OpenGL does is provide a means for your program to talk to the hardware.
• As an interface, it can be read from two sides: (1) how your program sees it, and (2) how the graphics hardware sees it.
• As a standard, the "how your program sees it" side is consistent for all hardware (barring obvious factors such as different GL_VERSIONs).
• Because different hardware is different, the "how the graphics hardware sees it" side will be different for different graphics hardware.
• Because different hardware is different, an OpenGL implementation that works for one hardware vendor WILL NOT work for a different hardware vendor.
• Because each vendor has different hardware generations, an OpenGL implementation that works for one hardware generation MAY NOT even work for a different hardware generation from the same vendor.

From all of that, you'll see that it's quite impossible for any language to support OpenGL by itself. OpenGL is not provided by a language; it cannot be provided by a language; it must be provided by the hardware vendor. Don't think of OpenGL as a library; think of it as a device driver (which is not too far off the truth). It's quite low level, it's very hardware-dependent.

So what would it mean for OpenGL to be natively supported by a language? It would mean that the parts of OpenGL that are hardware dependent (i.e. the interface as it's seen from the hardware side) could not exist. It would mean that something else would be needed to sit between the program and the hardware. But that "something else" would not be OpenGL, because OpenGL already clearly defines what it is, and it's not that "something else".

(All of this is deliberately ignoring pure software implementations - like Mesa3D - which you don't want to use as they are slow - I don't mean "slow" like 50% or 25% of the performance of a hardware implementation; I mean "slow" as in "you're lucky if you get 1 frame per second.)

Answer 4

This answers the main question: "So my question really is how would I be able to stick OpenGL (I would like OpenAL and maybe OpenCL too) in a single jar and nothing else?"

You may choose to place all the JogAmp JOGL 2.0 JARs inside your main JAR when you export your application using Eclipse. Use the "Package required libraries into generated JAR" in the Eclipse Runnable JAR export dialogue. By exporting like this will create a single jar file that will run on all platforms. http://forum.jogamp.org/Exporting-tp4029053p4029054.html

Answer 5

You can use LWJGL which is just one jar file (and natives) like you requested.

LWJGL is easy to install and includes openGL. It also includes openAL and openCl ( I think).