What's the status of the JSR?

General Discussions
#21

The KVM is optimized mainly for space is it not? While consoles would benfit from this… we still need speed. HotSpot is optimized for speed.
In general I don’t see the need for a specifc game VM, so long as there are two things available. 1) Hires timing facilities, 2) predicable GC pauses.
It would be great if instead of Thread.sleep(x); we had gc(x) - a request to garbage collect for x milliseconds. and some way of falling back to Sleep if the collector couldn’t use all that time for something useful.

When I asked if JGP could be implemented as an extension I was getting at the points you brought up: The PC alreadys meets the JGP hardware specs and therefore you are left with APIs. I had not considered that the VM itself would have different constraints, I guess that part could come as an improvement to the existing J2SE VM though.

The bit I’m trying to get at is that the J2ME and the Profile can’t be distributed with every game anyway - at least not without making the games hardware specific and throwing away a lot of the reason to use Java. And on the PC/Mac side of things it MAY be confusing to need several different flavours of Java. That is, telling the user that having the J2SE JRE is not enough, you need the J2ME JRE for platform X plus the JGP…
How would such a thing be delivered? The ultimate goal being to grab a “JGP compatible” game off the shelf and run it on any system that runs the JGP. How will the JGP get on to the PC/Mac/X-Box/PlayStation/GameSphere/whatever? Am I right in assuming that it makes no sense to distribute it with the game itself?
Is there a good enough reason for hardware companies to put such a thing on the machine to begin with in the case of consoles? (Much like you see with mobile phones now.) I don’t think the console Mfg’s will be ready to do something like that for a long time.

Java really needs to prove itself as a cutting edge game platform before that will happen. And we all know the difficulties involved with that. Java lags the cutting edge - it almost has to. First the new capabilities are added to the hardware (graphics card) then the native code has to be written to exploit those capabilities, then someone has to make a Java binding - preferably a standard one like Java3D… there is a built-in lag to Java supporting the ‘latest’ gaming hardware. [man, this is really getting off-topic] So I’m missing how Java is going to get to the consoles. JGP makes sense to me as a standard extension only in the sense that getting it to PCs should be much easier that way.

#22

2 Quick comments:

(1) KVM is an implementation, others are possible, but yes its intended for a tiny space.
(2) J2ME is much bigger Category then just KVM/CLDC, it includes CVM type VMs and its profiles, as well as JavaCard on the other end.

(I think I already disucssed where JSR134 fits in above.)

#23

Well in reality there isn’t much stopping Java from getting to consoles. The issue is purely a business one, not a technical one. For example it would take the better part of the weekend to port the KVM to a gameboy advance using the Nintendo GBA Developers Kit. The question then becomes ‘then what?’

As such the only companies that would partake in such a port would be Sun or Nintendo. Nintendo has shown that it doesn’t really have the desire - and Sun doesn’t yet appear to have the motivation and as such while the JSR will be the greatest thing to ever happen to Java from a gaming perspective - that doesn’t mean that we will get console capability… Sun would have to go to these console boys and present a good business case to get the JVM in the tool chain (that’s really all they have to do, because Sun can say whatever they want - if you don’t build a game with an ‘accepted’ tool or technology - you won’t be on a console).

Once its in the tool chain and developers can choose to use or not use it (won’t be in this generation - that’s for sure), then you may see people adopt it… though most game developers are very C/C++ centric and most of the ones that I know who’ve been doing it for 5+ years simply aren’t interested in doing Java development. The rest simply don’t see the point.

Even those who I’ve shown pixel shaded Cg goodness running from Java just really think of it as nothing more than a novelty. At most they are interested in building scripting engines in Java - but don’t see the point of doing much else.

#24

That’s because there simply isn’t a point.
For a game developer to give up C++ or even C (s)he has to give up these things:

  • access to any API or hardware they feel like using
  • performance
  • most of the canny knowledge they’ve acquired in another language
  • several useful features in the other languages that aren’t available in Java through bloody mindedness

The notional gain is one of productivity but if you’re writing a game for a console you’re pretty much on the bleeding edge of technology already and need to wring what you can out of them: so you will tend to spend more time coding around the limitations of Java and less time writing straight to the hardware.

The biggest killer will be performance and memory overheads. It’s just simply not possible to get away with Jeode-style performance on an iPaq when you see how incredible the games are on it written in C++. Insignia have been working on that ARM JVM for a good while now and its performance is staggeringly poor. A PS2 has roughly the same poke as an iPaq but I can’t see any half-playable games appearing on it with current state-of-the-art JVM technology. Quite apart from the fact the APIs will almost certainly be inadequate to extract the specific performance and features out of a PS2.

Then there’s still that myth that you could write a game in Java on PS2 and just run it unchanged on GC or XBox. Apart from the fact that XBox is sooo unlikely to get a JVM on it for general use, the graphics technology is so radically different to a PS2 you’d be pretty crazy to think you could shrinkwrap the hardware under one generic API. In the end you’d have to re-write most of the code that took care of the graphics. I’ve already got this problem under Win32 just trying to write code to ATI or Nvidia as they’ve got some pretty radically different ways of optimising rendering.

As the game code is likely to be written in very generic looking C++ I’d hardly say that portability of the logic would raise its ugly head. But in the end the gulf in performance and technique will not be bridged by a clever API. It’ll just boil down to one big, long, debugging and optimising and rewriting session and there goes your productivity, and all in the face of massive risk.

I may have ranted about this on the old boards but I feel like having another one :stuck_out_tongue:

Cas :slight_smile:

#25

Sad…but true.

If you are serious about gamedev (which means minimising risk at all levels) why would you even bother with Java when there are already a number of high-end cross platform engines available…intrinsicAlchemy, renderware, NDL etc.

Even excellent mid-range “dirty Java” solutions such as Wildtangent now have some uncertainty due to the Microsoft/Sun JVM fiasco. Though to their credit WT seem to be committed to Java (http://devforum.wildtangent.com/cgi-bin/ib3/ikonboard.cgi?s=3dbca20724ccffff;act=ST;f=1;t=884) as their main language, though they support a lot more.

To my mind WT are showing the best and most intelligent use of Java for gaming…use it at the application level (much easier to use than C/C++) and leave the grunt work to faster native code. There are enough problems optimising the application level when developing a complex game without having to worry about low level Java efficiency.

Do you want to make games, or do you want to make game engines?

FYI…intent JVM (www.tao-group.com) has serious speed advantages over insiginia.

#26

There is actually a JSr that defines much of this. (68 I believe but thats from memory.)

Basically a profile can include “building blocks”. A standard extension can be considered a “building block.”

Clear as mud?

#27

It has occurred to me that a Profile might not be complete without some indication of its minimum performance.

To this end you’d need some kind of nontrivial benchmark application. Bit of a problem. At least in the PC world you can vaguely state that you need an 8Mb 3D card, 32Mb of RAM and a 400Mhz processor and be reasonably confident about the performance of the game.

How might a Profile have a minimum performance rating associated with it? SPECjvm? Suggestions?

Cas :slight_smile:

Cas :slight_smile:

#28

Yeah, I tried to touch on building blocks in my other posts. Basically building blocks makes it possible to break all of the Java functionality into a bunch of standard extensions and then define some arbitrary profiles that include only certain bits of Java - and that RULES! When that happens I see J2SE as either reinventing itself or becoming nothing more than a system that includes every building block.

#29

Hm, how about a J2SE JVM distro which includes the bare minimum of classes to be able to start a JVM and begin loading the rest of the classes it needs from a “provider” (ie. Sun), one by one, and storing them?

You could version each class individually and provide detailed version dependencies. Then the “provider server” would automatically be able to keep your JRE core code completely up-to-date on a micro level and the initial download hit would be very small indeed.

Cas :slight_smile:

#30

I thought you were knocking this idea on “the old board” because it required web access after the initial install. Did you change your mind about that? :wink:

#31

Oh, no, this is a general J2SE distribution thing - I think the Java Plug In should arrived packaged like that or it’ll never compete with Flash.

It’s still no good for game deployment, where the only solution would be to have a bare VM and free license to distribute the core classes you need for your application, and embed the VM in your installation. Somehow. (I’ve given up on that anyway - it’s Jet for me now).

Cas :slight_smile:

#32

Okay… we’re clearly out of summer, and still nothing.
I guess that the specs will be huge, as it covers other apis and as far as my english skills permit me to understand, changes to those other apis may occur to accomodate jsr134.
Wouldn’t it be clever to release specs of the different nine domains of the jsr as soon as they are ready? I mean, it’ll be very long to read and check if we get tons of docs to read on one shot. Starting the job ahead of time might get us to the implementation faster and give time for reading first domains.
My 46¤cents :slight_smile:

#33

Maybe someone could clarify the timeline of the JCP and where the JGP Expert Group is in the process?

The way I have understood it, us non-JCP members will not get to see the spec for at least another four to six months or so. First it seems that the community release that was supposed to happen in Q3 got delayed, and even when that release does finally happen, us non-JCP members will have to wait another 3 or 4 months for the public release of the spec before we get to look at it, correct?

#34

Getting back OFF-topic…

I may be a decent programmer, but I sure as heck don’t have a clue when it comes to the differences between the various editions of Java. I admit that there are differences, but would it not have made sense for Java to have become nothing more than a JVM and Profiles for EVERYTHING? That is to say, J2ME and J2SE would refer to different JVMs, but nothing else, and everything else, such as java.lang.String, or javax.sound.*, be part of a profile?

Course, I could be suggesting more work for everyone, but it seems to me that this kind of defintion earlier on would have made it REALLY EASY to define the minimal set of code required to write a game in Java, either for a cellphone or for a PC, and therefore would make it pretty plain what to include/exclude from the Gaming Profile.

Then again, I could just be really frustrated at what I’m programming. ;D

#35

To be honest with the speed at which we’re pushing out lwjgl, by the time the JSR finally does show up - I’m not too sure I’ll still care.

#36

This is the most mysterious JSR and API spec release in the history of computing, still nothing!

It’s either cancelled, or it will cure world hunger when released.

Hello?!?! Anybody out there?

#37

One thing is sure. JCP suffers from opacity. Not being able to at least know what is happening between the various persons and the direction things are headind discredits the process.
JCP should be called FUD. (Finished at Undetermined Date) :-[

#38

Maybe JGP’s target isn’t ps2. JGP will be launched with ps3. 2005…
:-[

#39

[quote] Maybe JGP’s target isn’t ps2. JGP will be launched with ps3. 2005…
:-[
[/quote]
JGP has nothing to see with PS3 specifically.
Hopefully, we’re not using java to be tied to a certain platform.:slight_smile:
PS3 is not different from any other platform in that case.

#40

one of the JGP’s expert mebers is SONY. maybe xbox-next will be tied with direct X. GC may adopt JGP, but JGP’s process is very very sloooow. No one knows JGP’s timeline, spec, etc… And no one waits JGP’s official debut eternally. Only Sony and Sun know its timeline, spec.