I see that the JSR has been voted and approved (I think), but when will we see more details?
I think after you guys went to that game conference you were going to post more details or maybe even some early idea of an API.
Any new info? What’s going on?
Well, I still need to be careful what I say, guys. Thre are confidentiality issues and I assume you want me to still be around in the near future ;D
We’ve got quite a few of the areas well defined now. Currently some work is beign done on the physics APIs that looks very promising.
Hopefully we’ll have a chance to say something more public in the not too distant future…
:oPhysics APIs? Okay now you’re scaring me. I thought the goal was to be something small, not all encompasing. ???
You might want to take a quick peek at the JSR;
http://www.jcp.org/jsr/detail/134.jsp
The proposed specification is of a J2ME Profile that covers nine areas of game development:
Augusto,
As the owner of a company building a game, I had been tracking some of this, but for some reason, I have read JSR-134 many times and NEVER once did the “J2ME” part click until this morning.
What kind of an effect would that have on writing a game, do you think? Actually, is there a Windows or Mac J2ME JVM? If not, (and yes, I am inexperienced in the usages of profiles) could a profile be used using J2SE?
I especially liked the 2D and communications part.
[quote]Augusto,
As the owner of a company building a game, I had been tracking some of this, but for some reason, I have read JSR-134 many times and NEVER once did the “J2ME” part click until this morning.
[/quote]
I also “missed” the J2ME part when I read about this before, guess I wasn’t paying much attention.
J2ME is also mentioned prominetly in the JavaOne slides for this topic;
http://servlet.java.sun.com/javaone/resources/content/sf2002/conf/sessions/pdfs/1243.pdf
(requires registration)
Well hopefully Jeff can explain that, but from what I can undestand, this stuff should work on a J2SE VM, as J2SE is a superset of J2ME.
Oh boy, a question I can actually answer without violating my confedentiality agreements.
The JGP (JSR134) is a profile. This means that is a subset of existing APIs and/or new APIs that, together, define a complete and legally detributable Java Platform. So, for instance, if the JGp didn’t include java.sql* in its description, a JGP distribution woudl nto have to include java.sql.* classes.
Now a profile is only legal in J2ME, thus the JGP is a J2ME spec. This does not however mean that its intended for cell phones. J2ME ius a very wide catagory. If you look at the JSR you wil lsee it targets the very high end of J2ME-- modern game consoles and maybe some very high end set top boxes. Its is a CDC, not CLDC, profile which means it requries a full Java2VM (but not JDK class libraries.)
You will ALSO notice that there is some ervbage in there referring to desktop systems (PCs, Macs). Thsi is an unusual effort in that it is intended to streatch into areas that ae traditionally J2SE territory. Whether that is accomplished by a J2ME on those paltforms, or by a “compatability set” of libraries that are added to J2SE to make it a JSR134 super-set is soemthing thats still undecided.
But rest assured, our goals include JGP compliant programs running on the desktop.
Hello friends,
I can’t find much info regarding the JGP in java.sun.com. So
please give me answer to the following questions.
Does the JGP makes the current full screen api in jdk 1.4
obsolete ?
Is the intention of JGP a full multimedia api like directx ?
How is it related to various java editions (j2me,j2se). Does
it have a seperate gaming VM ?
JGP Canceled?
The white paper that was distributed at the GameDevelopers conference will be available in the documentation section of the new site. You will be able to get it next week.
-Chris
P.S. No, JGP not canceled
Jeff, thanks for the answer… but I’m still trying to wrap my head around this “profile” thing.
Is what you are saying that I will be able to use the full J2SE set for writing my game, along with the classes for JGP, if I choose to? Or am I FORCED to use J2ME and the JGP profile?
When can we start programming using the JGP.
When will it be released for developers ?
J2ME CDC and CLDC define a minimum specification of the capabilities that a type of device must have. CLDC is geared towards palms, phones and the like. CDC is geared towards more capable boxes such as consoles and PCs.
Once you get back the capabilities you come to the profiles. The profiles for all practical purposes define the software requirements that the device must support - or in another way, it defines the APIs that must be available. There is in fact a Personal Basis profile which is pretty much a redefinition of what J2SE is - just without the bloat.
When talking about cell phones and such you’re talking about CLDC and MIDP… very very limited stuff, though nonetheless pretty cool. MIDP revolves around the KVM (for all practical purposes). The KVM is an absurdly low memory requirement JVM… and it still can do a lot. MIDP doesn’t have anywhere near the API set available in J2SE, no crypto, no JDBC, no XML parsing, no JNI, no specialized classloaders, etc. I’m a fond fan of MIDP, but MIDP has its faults and as it sits today would never work for PC games or console game … but would possibly work on a gameboy advance if someone did the port.
So from what the JSR says and from what is clear about the architure of J2ME and its profile/unit based design - you will be able to depend on a machine running with certain requirements and resolutions. Additionally you will have a hard defined API that you can use that must be present on anything that wants to call itself JGP compliant. This doesn’t mean you can’t have additional .jar files to do other functions - just means that you will have some already defined APIs for (apparently) doing everything you need for game programming.
Personally I think these additions (like a physics API) should have never been defined as part of the profile because physics is a very genre specific thing, but because a profile is a standard API - you will get the JGP implementation whether you want to use it or not. Should have just been an extension IMHO. Unless, of course, the JGP is somehow violating the contract of J2ME contexts and profiles
In any event, J2ME is good stuff… I only hope that with things like the Personal Basis profile and the like, that J2SE dies a rapid death and that everything becomes a J2ME profile… as it should be.
J2SE die? That seems rather harsh… But I get your point - it is a bit bloated… I would like to see more partitioning into ‘standard extensions’… But currently the standard extensions don’t get the support they deserve… most are still not available as auto-downloads for Java Web Start for instance… a HUGE oversight IMHO.
Which brings me to my somewhat on-topic questions…
It seems there are similarities between ‘standard extensions’ and J2ME ‘profiles’. Could someone clarify exactly where each fits? How they differ? How they are similar? How would JGP on a PC/Mac be implemented? Could it be implemented as a standard extension on J2SE? Or must there be a lightweight runtime for the desktop - a J2ME implementation of PC/Mac?
Scott
It strikes me that there should have simply been a raw JVM at the baseline with java.lang in it and nothing else, and everything should have been an extension optionally downloaded from the JVM vendor. Now that’s what I’d call J2ME. If I ruled the world.
It would help, too, if the JVM binaries were a little smaller. I noticed that it’s creeping up and up in size. But then, quite a few of the .dlls in there are to support Java APIs anyway.
But mostly it would help if it were on a coverdisk somewhere ;D
Cas
[quote]
Hello friends,
I can’t find much info regarding the JGP in java.sun.com. So
please give me answer to the following questions.
I’d say a full game programming API (or rather set of APIs) like DirectX, but the answer is yes.
See my discussion above about profiles and the intent to have compatability inot the J2SE space. I think I fully addressed this already. If not, tell me whats missing.
[quote]Jsonally I think these additions (like a physics API) should have never been defined as part of the profile because physics is a very genre specific thing, but because a profile is a standard API - you will get the JGP implementation whether you want to use it or not. Should have just been an extension IMHO. Unless, of course, the JGP is somehow violating the contract of J2ME contexts and profiles
[/quote]
Thanks for the summation greg and good job.
As for physics we are trying very hard to give you the common tools without imposing a specific game model on you.
When we hit review you can tell me how well/poorly you thin kwe’ve accomplished that
Which brings me to my somewhat on-topic questions…
It seems there are similarities between ‘standard extensions’ and J2ME ‘profiles’. Could someone clarify exactly where each fits? How they differ? How they are similar? How would JGP on a PC/Mac be implemented? Could it be implemented as a standard extension on J2SE? Or must there be a lightweight runtime for the desktop - a J2ME implementation of PC/Mac?
For the sake of discussion I will try to describe how this would most likely work (though only the Sun folks could say for sure). So you have this thing called the Connected Device Configuration (CDC). Basically it would say things like the device must have at a miminum a certain amount of ram and rom. Note true physical storage is never mentioned as the interface to persistence is a little bit more abstract in J2ME (which as it works out is a very good thing). The CDC is a bit different from the Connected Limited Device Configuration in that you can assume a less limited connection to the network. So in terms of a PC or Mac, the CDC would really just say that in order for your machine to cut the mustard, you must have a certain amount of RAM. No biggie, any PC out there will fit the bill.
Next we come over to the profile is what JGP is (Java Gaming Profile). The profile further specifies the capabilities the device hust have, including resolution and bit depth as well as the input devices. The Personal profile requires that a machine have 2.5MB ROM and 1MB RAM. I would guess that the JGP will have much larger requirements than this. So now your device will be checked to see if it has these requirements (note that this is machine specific implementation stuff just like a JVM). Okay so now your specialized JVM (and I will guess that the JGP would use a more upgraded version of the KVM and not subject us to the pain and unpredictability that is the standard JVM and all its hotspot madness ;D
Next will come a set of APIs. This of this part as redefining Java all over again because while there may be similar APIs in J2SE - or the same package structure anyways, you would use a different bootclasspath to signify a different set of core classes and behaviors. Thus while you may be using java.lang.String - what is being used and compiled under the covers is actually a different implementation of String specifically for this profile. Writing an entire profile (as these folks have done) is a non-trivial excerise.
So in a sense your standard extensions may or may not even be compatible with the JGP depending on how its implemented (probably not - to engineer out much of what we don’t want would require some core changes to some fundamental APIs).
JGP would be implemted as a JVM (maybe the standard one, maybe the KVM, maybe something new altogether) and a .jar file that would describe is API.
Could it be implemented as a standard extension to J2SE? NO! If it were a standard extension to J2SE is would most definitely not be anything near what you’d achieve with J2ME. What you’d have is just an API in a jar and all the bloat and nastiness of J2SE coming along for the ride. Thing of J2ME as a ‘second chance at doing the client side cleaner.’ You wouldn’t want this as a standard extension, it would defeat the whole point of doing it in the first place. In reality a standard extension version of the JGP is pretty much what Java3D provides.
Must there be a lightweight runtime for PC/MAC - yes. Unless the Sun folks cheat and repackage the standard JVM (which would be a mistake IMO… the kVM is more than capable for our tasks) - we should be looking at something that sits on top of the kVM. However it has been said that it also rides on top of the CDC so that almost lends itself to be a much larger JVM like that of J2SE - unfortunately. What’s really needed is a specialized JVM to handle gaming tasks. The other good thing would be that the kVM 's source is readily available allowing any random joe to port the core of JGP to another platform in relatively short time (the kVM is fairly standard C code).
So I’ve somewhat entered the realm of speculation to cover what I think they’ll do, but of course I’m looking at the ideal situation - and I don’t have to base my view on a timetable or budget (specifically with respect to modifying the KVM).
It strikes me that there should have simply been a raw JVM at the baseline with java.lang in it and nothing else, and everything should have been an extension optionally downloaded from the JVM vendor. Now that’s what I’d call J2ME. If I ruled the world.
You should take a look at what J2ME provides. J2ME doesn’t specify that any particular API set be available. In fact there is nothing stopping you from defining some random profile that only has that functionality provided! When I first looked at the MIDP API and looked at the API for the lightweight java gaming library I thought that outside of a few areas they are fairly equivalent and trying to accomplish the same thing. While LWJGL provides a lot more functionality (and in a way is a lot heavier that MIDP), LWJGL could quite easily be adapted to being a profile that sat on top of the KVM… kinda… since you’d also have to modify the KVM to handle the same NIO buffer structure you want to pass to OpenGL.
Take a look for yourself and you’ll see why I consider J2ME (MIDP) the last saving grace/chance for client side Java. Sun would do well to replace applets with Midlets as soon as possible. It not only would give them a cleaner (and greatly more uptodate) programming model, but it would also allow phone developers to take their wares back and forth to the PC public.
The network layer is a work of clean engineering with a focus on simplicity… as is the record store (though not quite as clean). All in all I think the MIDP is excellent… missing some absolutely critical features through which Microsoft will rape them if they don’t release them soon (sitting at CNN I have the fortune/misfortune of seeing lots of goodies coming down the pipe), but excellent nontheless.