Re: Java as an API (Re: Article on state of graphics drivers on BSDs)

[Martin <martin.kelly4000%gmail.com@localhost>]

> On Thu, Feb 14, 2013 at 6:19 AM, Julian Coleman <jdc%coris.org.uk@localhost> wrote:
> Hi,
> I think that this is both a strength and a weakness.  As you mention, if
> you code in java, then the code runs on any JVM (modulo bugs).  There might
> be problems related to speed or missing API's, but the major problem for
> this case is the way in which a java program and the JVM execute code.  It
> is something like this (simplified):
>
>       java byte code (application program)
>                   running on
>              java virtual machine
>                   ported to
>        operating system/hardware platform
>
> So, even if all the graphics code was written in java to a common API, we
> would still need to port a JVM to all the operating systems and hardware
> combinations that we want to support.  This is probably a larger job than
> porting the current graphics API's.

Hey, Julian
Time was always going to be a factor no matter which way you slice it. 

Yeah speed was another concern, but i can't think of another programming language that can do the same thing as Java, can you?

Can
 you refine what you mean by hardware combinations? Are you talking 
graphic card models (e.g. Tesla, Geforce, AMD Radeon HD, etc)

Correct me if i am wrong, but isn't that the benefit of Java, that once you have JDK &/or JRE its only a matter of creating the build environment for that software to run?
Does this not mean that any existing Java based program is already running within a JVM, as the only requirement is JDK &/or JRE ? 
Which if so, doesn't that mean that the code for running a JVM already exists on said system, thus porting a JVM to all OS you want to support is simply copying JVM code already in use from that system and maybe re-writing parts that are irrelevant.

Take for example Minecraft... (not the greatest of examples) but its a game that is based of Java and it is totally platform independent. In order for Minecraft to work on any OS it just needs JDK or JRE.

The big question is, is it worth taking the extra time to make them "less restricted"? 
If hypothetically we say it is, well maybe its worth seeing if we can get other the other *BSD communities on board and see if they have developers willing to work on it, as the effort would also largely benefit them too.

I believe in this case the easier option isn't the best option... NetBSD has the better position than FreeBSD or Linux atm. If we take a look at all the troubles and problems that have arisen from how the KMS and GEOS modules are implented in both distros (especially Linux). They have been hell for both and Linux still isn't out of the woods, now with UEFI secure boot they are basically going to introduce portions of these drivers into kernel space; because as it currently stands secure boot won't allow any form of user injecting arbitrary code at run time.