Java Version of Celestia??

[HankR]

Lately I've been thinking about the idea of doing a Java version of Celestia.

Good idea? Bad idea? What do you think?

- Hank

[slashi]

Little worth to spend recourses for such porting. AFAIK Celestia is C/C++ and OpenGL based application. Any hardware platform that is capable to run OpenGL probably has C compiler. So what for we need Java based Celestia?

[NecroBones]

Also, I'd be rather impressed if a java version would be anywhere near Celestia's current level of detail and performance. Generally speaking, compiled C/C++ is always going to be better. :)

[HankR]

Granted, C/C++ will always be faster than Java. But since most of the load is being carried by the OpenGL library and graphics processor, maybe Java for the rest would be fast enough.

The main advantage of Java would be improved portability. Yes, most platforms have C/C++, but there are often subtle incompatibilities. Also, the GUI has to be implemented on a per platform basis. Java could avoid this.

- Hank

[Guest]

Because Celestia is a client application (where Java is not strong), and not a server application (where Java is dominant). I would think that a Java version would be an exercise in fun and education rather than practicality.

Speaking personally I would love it, as I prefer Java to C++ and would find it a lot more natural to read the code, but that is me, and I usually do server side coding. If someone else wants to start the project I would contribute from time to time for the fun of it and my own education.

----------
Dave

SpaceGear.Org
Open Standards for Space Flight Simulation (tm)

[HankR]

I think Java hasn't made much headway for client applications mainly because of the Wintel duopoly's dominance on the desktop. Wintel users and developers have little to gain from portable applications (everything is developed for Wintel first anyway, and the rest of the market is too small to matter) and Intel and Microsoft have a lot to lose if applications are easily portable to their competitors' products.

But if portability is important, Java has a lot to recommend it. One of Celestia's attractions (for this Mac user) was its cross-platform availability. The long delays in the Mac OS X port seems to indicate the difficulties of the current approach. If Celestia was in Java, these difficulties might be largely circumvented. That would be a big win for non-Wintel users.

- Hank

[chris]

I spent a few years programming almost exclusively in Java, and I did think briefly of using it for Celestia. Java does have quite a few advantages for cross-platform programming--most importantly, a rich standard library. But a number of factors led me to choose C++:

While a Java runtimes are available for free for nearly every platform, not everyone has it installed. I wanted it to be very simple to get Celestia up and running; requiring a Java runtime to be present means that fewer people with bother with Celestia.

3D graphics support. Java3D is not an option . . . I wanted to be able to use the latest graphics hardware to the fullest, and OpenGL and Direct3D are the only choices for that. There are libraries that let Java use OpenGL, but this is just another item that people would have to install before they could use Celestia.

Performance. Celestia is not always a rendering-bound application . . . Things like visibility culling a 100,000+ star catalog and tesselating planet surfaces require a significant amount of CPU time.

There were some other miscellaneous reasons . . . Working with vectors, matrices, and quaternions in C++ is a lot easier than in Java, because C++ has operator overloading and stack objects. C++ templates are also very useful; one very basic use is that there's a single code path for single and double precision math objects.

I don't plan on porting Celestia to Java . . . it's a lot of work, and I think that the end result would be a slower, more memory-hungry, and trickier to install version of the current Celestia application.

--Chris

[Sum0]

So how's the upcoming BASIC version?

10 PRINT "Earth"
20 PRINT "/-------\"
30 PRINT "|-------|"
40 PRINT "\-------/"
50 PRINT ". . . . ."
60 PRINT ". . .. ."
70 PRINT " . .. ."
Ah, this brings back memories...

[HankR]

...Wintel users and developers have little to gain from portable applications (everything is developed for Wintel first anyway, and the rest of the market is too small to matter)...

Hank, I think you kind of answered your own question here.

I think it would be cool to strip the control portions of the app out and just use the C++ stuff for the actual rendering engine. So you would have a big window that was only the display. It would respond to something like SOAP RPC's that you would send to it through a socket, and then use something like TCL to do all the ugly user interface stuff. To me that would be far more interesting than a straight language port.

------
Dave

SpaceGear.Org
Open Standards for Space Flight Simulation (tm)

[dtessman]

I didn't realise that it had held over your name when I did the quote.

----
Dave

SpaceGear.Org
Open Standards for Space Flight Simulation(tm)

[Billybob884]

A java version of Celestia seems essentially useless because, correct me if I'm worng, but first of all, wouldn't the file size be huge? Second, I really don't think you would get graphics anywhere near as good as the current openGL version. And third, it would be very demanding on one's computer.


Mike M.

[chris]

I think it would be cool to strip the control portions of the app out and just use the C++ stuff for the actual rendering engine. So you would have a big window that was only the display. It would respond to something like SOAP RPC's that you would send to it through a socket, and then use something like TCL to do all the ugly user interface stuff. To me that would be far more interesting than a straight language port.

Something like this would be both easier and more productive than switching the whole code base to a different language. Celestia is architected with a project like this in mind . . . all of the core functionality--rendering, database handling, math, etc.--is handled by libraries that are compileded independently of the UI stuff.

--Chris

[jrobert]

So how's the upcoming BASIC version?

That's actually not a bad idea considering the power of Visual Basic 6 and Visual Basic .NET. Perhaps Celestia can actually be ported to this programming platform. Fun? Perhaps, but not as practical as programming in C++. But again... it would be interesting.

[HankR]

I really appreciate the comments from Chris. He does a good job of summarizing the reasons why Celestia is in C++ rather than Java. I'm obviously in no position to argue.

The one point I hadn't thought about was the difficulty of installing Java/OpenGL on Windows. (I'm sure the Linux boys could handle it.) A high-performance JVM comes pre-installed on Mac OS X, and I installed the GL4Java JNI package with just a few clicks. I didn't consider how hard it might be on Windows.

I'll grant that operator overloading, stack objects, and templates are a big convenience for the math coding, but I think I could probably manage to live without them. (Athough admittedly they would likely be the biggest pain in trying to do a port.)

Performance is the key question in my mind. I'm not sure if it could be made acceptable, although I don't think it would fall as far short as some people seem to believe. Also, JNI/C could perhaps be used to optimize the most severe performance bottlenecks.

It's true, as Chris says, that porting Celestia to Java would be a lot of work, and the end result would be a slower and more memory-hungry version. On the other hand (and I know I'm whining here), for us Mac OS X users the "current" Celestia application has been stuck at 1.2.2 for months now due to porting difficulties, so we're missing out on lots of new Celestia developments. It's definitely frustrating.

Yes, I understand that most of the work on the Mac OS X port has been devoted to a spiffy new "Aqua" interface that will undoubtedly be worth the wait. And hopefully, going forward, porting new versions of Celestia to Mac OS X will require a lot less work. This will ease my pain.

Of course, I do realize that "write once, run anywhere" is really an impossible dream, at least in our lifetimes. But, hey, ya gotta have dreams!

- Hank

P.S. The idea of doing Celestia in Basic is ridiculous.

[HankR]

Please note: the P.S. in my previous post was intended as a response to Sum0's joke, not jrobert's comment on the power of VB6.

- Hank

[jrobert]

On the other hand (and I know I'm whining here), for us Mac OS X users the "current" Celestia application has been stuck at 1.2.2 for months now due to porting difficulties, so we're missing out on lots of new Celestia developments. It's definitely frustrating.

Perhaps an alternative would be to run the Windows version on the Mac. I do believe there is software (or hardware depending on the manufacturer) out there that lets Mac users do that. I remember for Mac OS 6. , that there was SoftPC and also OrangePC. OrangePC was the hardware add-on to the Mac but this is a different topic and one which probably doesn't quite fit in here.

[HankR]

There's a PC emulation product from Connectix called VirtualPC which actually does a very decent job for many Windows applications (works great for FreeCell). Unfortunately, it doesn't support graphics-acceleration hardware, so it wouldn't work for Celestia.

- Hank

[NecroBones]

So how's the upcoming BASIC version?

10 PRINT "Earth"

LOL... Yeah, I could just see an ANSI/ASCII "graphics" version... Talk about an extinct method of doing visuals... well, almost. :)


[/code]

[Miserableman]

So how's the upcoming BASIC version?

10 PRINT "Earth"
20 PRINT "/-------"
30 PRINT "|-------|"
40 PRINT "\-------/"
50 PRINT ". . . . ."
60 PRINT ". . .. ."
70 PRINT " . .. ."
Ah, this brings back memories...

This made me laugh out loud

[etrepum]

I don't think Java would fix a single UI issue, Swing is a nasty beast.. All you really need to do is create a wxWindows UI, which would work fine on win32, linux, and recently os x (sort of). There's even an opengl context for wxWindows.

In any case, the OS X port isn't "difficult" really, not anymore... I have all the hard stuff already done and in CVS, I just don't have the time to finish it off. Nobody else has taken the initiative to do anything at all regarding the port, so the real difficulty is just finding someone who has time do it, not actually doing it.