Java: Where To Next?

[todd]

I've decided to develop in Lisp for the Pandora, nothing is more beautiful or powerful IMHO. More specifically, I'll be using the Chicken Scheme-to-C compiler. Chicken supports embedding C(++) into the code, yum.



Chicken looks mighty interesting. Maybe I ought to borrow SICP and give it another read. I would enjoy a thread (and/or a wiki) for Pandora Schemers. Do you have much past experience with Scheme?

--Todd

 

[Dutch_Cap]

Not much, no. Until recently I've mostly dabbled in Common Lisp (with special thanks to the most excellent "Practical Common Lisp" by Peter Seibel). So far Scheme is similar enough to pick up quickly, though. I think I like it slightly better too.

By SICP you must mean Structure and Interpretation of Computer Programs, which I hadn't heard of before. Would you recommend that?

 

[JamineBourne]

Thanks for the advice, but a couple of quick questions in regards to SDL:

1.) Is it something that I "install" and then import it via a line of code to be used later? (I seriously doubt that though )

2.) Is it necessary for checking events like button presses and analog stick movement?

3.) Is it necessary for loading and displaying images in the program?

4.) To me it appears that SDL is implemented in a bunch of languages, Java among them, so is there a difference between JSDL and SDLjava?

 

[TrevorBradley]

Returning to the field a few years ago, I picked up Java. I have to ask: why go back to unmanaged memory and pointers? Java is a lot nicer IMO. Not to mention the fabulous (intimidating at first, but fabulous) standard libraries (collections, etc.). People still trot out the old "Java is slow" argument from time to time. But the latest JVM's from Sun are really quite amazingly optimized: slow code is much more likely due to problematic algorithms than to JVM overhead. Do I sound like a fan?


No, you sound like an informed individual . It's true, that java isn't nearly as slow as it used to be. However the garbage collection still has many problems with memory-intensive applications. Java can be programmed memory-smart, but at the cost of that trademark clearness. Sometimes it's just easier for everyone that you have destructors and a delete command as opposed to "I do it when I get around to it" garbage collector and finalizers.

I've been scratching at C++ for PandoraPanic. Ugh. No doubt my code would make a "real" C++ coder cringe. But ugh. I thought about buying a book & trying to learn C++ properly, but I'm not so sure that's a worthwhile endeavour for me.

Be careful which book you buy if you do though. There's a lot of crap on the marketplace . I'd recommend the book written by C++ specialists in my university, but unfortunately it's only in finnish.


I remember writing a multithreaded Java server back in 1999. Running the garbage collector manually every 10 minutes was required to keep memory usage from going too crazy.

O'Reilly is the gold standard for books in English. I'd strongly recommend any O'Reilly book for learning programming in any language.

Thanks for the advice, but a couple of quick questions in regards to SDL:

1.) Is it something that I "install" and then import it via a line of code to be used later? (I seriously doubt that though )

2.) Is it necessary for checking events like button presses and analog stick movement?

3.) Is it necessary for loading and displaying images in the program?

4.) To me it appears that SDL is implemented in a bunch of languages, Java among them, so is there a difference between JSDL and SDLjava?

1) Yes. Depending on the platform you're using.

You install the SDL-dev libraries, then link to them in your own code using an:

#include "SDL.h"

line at the beginning of your file.

Then when you compile, you have to include the library in your command line like so:

gcc myfile.c -l SDL

2) It's not necessary, but it helps. I'm using it to pick up keystroke and joystick SDL_Event data in my games.

3) It's not necessary, as there are other technologies for displaying graphics, OpenGL being the big alternative. But it's a good place to start.

And I'd love an answer to 4 myself.

 

[JamineBourne]

It looks like to really get a handle on SDL I need to learn C, as there doesn't seem to be too much information on the SDL binding for Java besides the javadocs on JSDL. The lazyfoo tutorials look promising once I've gotten some C implanted in the brain. B)

But I also just came across this: "LWJGL" I was interested when I saw the tutorial that wrote a space invaders game in java, then changed it to JOGL, then changed it to LWJGL. Would this be a better option, or is OpenGL not supported by the pandora? (not OpenGL ES)

 

[todd]

A side note re: books:

For whatever reason, I have found Flanagan very helpful (Javascript, Ruby). I thoroughly enjoyed van der Linden's introductory Java book -- not an O'Reilly title. O'Reilly has some good stuff out there -- and also some duds. Don't buy something just for the cute animal on the front.


Another side note: in order to avoid further hijacking this fine thread, I've created another one for further discussion of Scheme and the Pandora.

 

[Kramy]

No, you sound like an informed individual smile.gif. It's true, that java isn't nearly as slow as it used to be. However the garbage collection still has many problems with memory-intensive applications. Java can be programmed memory-smart, but at the cost of that trademark clearness. Sometimes it's just easier for everyone that you have destructors and a delete command as opposed to "I do it when I get around to it" garbage collector and finalizers.

I really have to agree with you here. Quite often I've wished that I had a way to manually delete objects - and actually, entire classes.

Sometimes I won't be using a class anymore(ex: a settings file loader), and I want to turf it out of memory. Currently I just have to hope the JVM will garbage it at some point. :lol:

I'm a Java developer by trade, and I definitely agree with you that JVM performance isn't typically much of an issue these days. In large part, this is due to the continual improvement of the JIT. While the JIT is maintined on x86 and SPARC, I'm not sure if there is a version targeting ARM which means we may only have an interpreted JVM for the Pandora.

Java's garbage collection model can of course, be both a blessing and a curse. 20 second pauses for a full mark-sweep collection are not a good thing in a web application. I've found that while you can gain some significant improvement through tuning the VM parameters, garbage collection certainly doesn't save you from your own mistakes(not that you stated or even implied that it does, but people often end up thinking garbage collection means you don't have to worry about memory management).

Your post was packed with goodness.

Java on x86 is incredibly fast - perhaps even faster than C, in some cases.

I needed some auto-resizing arrays for something, so my first thought was to use ArrayLists. I wrote a wrapper class that ensures the ArrayList boosts its capacity adequately, so that wouldn't constantly be resizing the entire array. Then I got curious... would an ArrayList coded in java be faster than a library ArrayList? I rewrote the class in java, how I envisioned an ArrayList to be coded, and included chunk-resizing that matched the ArrayList+wrapper.

It ended up about 40% faster than the library ArrayList for get(), and 100% faster for add(); the tradeoff was it was locked to a single type of object. I can't remember exact numbers, but it almosted halved the time taken by a sorting algo.


I believe we will be limited to interpreted Java on the Pandora - unless something happens with Mono. Still, interpreted isn't bad - JamVM's 100% interpretation seems to perform better than both Cacao and Kaffe.

Sun's ARM JVM is Headless, and seems to have great performance, but it costs money to license it. I enquired to them about it, and unfortunately the price isn't low enough that it wouldn't affect the price.


One thing to remember about Java - you do have to consider heap fragmentation. If you're creating new objects all the time, find a better way to do something.

4.) To me it appears that SDL is implemented in a bunch of languages, Java among them, so is there a difference between JSDL and SDLjava?

Since someone else answered the other three, I'll tackle #4.

-SDLJava is old and incomplete.
-JSDL is older and more incomplete.

But I also just came across this: "LWJGL" I was interested when I saw the tutorial that wrote a space invaders game in java, then changed it to JOGL, then changed it to LWJGL. Would this be a better option, or is OpenGL not supported by the pandora? (not OpenGL ES)

I also looked into this. I talked with some of them on the IRC channel, and determined that getting LWJGL to work on the Pandora will be fairly difficult. First, it has some dependancies that have to be met:

-It works on top of AWT/Java2D, but with hardware acceleration. The first task is getting regular java stuff to run on the Pandora like any other app.
-The second task is recompiling the lwjgl DLLs to take advantage of the Pandora's hardware. It can use OpenGL, but not OpenGL ES, so this will be a massive task.

General consensus was, SDLJava would be easier to fix up. And getting AWT working, then jumping right to OpenGL ES, might be even easier.

 

[Xmas]

One thing to remember about Java - you do have to consider heap fragmentation. If you're creating new objects all the time, find a better way to do something.

That's true for heap allocations in other languages as well, though. Yes, local objects may be allocated on the stack in other languages, but a smart VM can do the same through escape analysis. And a compacting GC can actually solve the heap fragmentation problem (at some performance cost, naturally).

Having control over memory management can be quite useful. But one of the most annoying things about C++ is that this is the default, and there is no single standard, built-in way of automatic memory management. There are just too many different smart pointer implementations around.

 

[Klepto]

C++ is beautiful.

I'm not a fan of C++, C has it's admirable qualities. I understand why people say ruby and python are beautiful, but I think they are only beautiful to the programmer and not the computer. The most beautiful language to the computer is assembly, which is also beautiful to most programmers I think. IMO the best compromise between the two are things like lisp and (yay!) forth.

I don't know about Java on Pandora, but historically Java on Linux PCs has been memory hungry. If you plan to use Java then I'm sure there will be SDL bindings of some sort. JLWGL and JOGL may be worth looking at, but I don't know how much work it would take to make them work on Pandora. If you want to use something else then C++ is a good choice, it's similar to Java in many ways and it's what people use.

 

[senquack]

Java on x86 is incredibly fast - perhaps even faster than C, in some cases.

I'm not an expert, but this seems false.

 

[TrevorBradley]

Sometimes I won't be using a class anymore(ex: a settings file loader), and I want to turf it out of memory. Currently I just have to hope the JVM will garbage it at some point. :lol:

System.gc();

Don't run it all the time, but once every few minutes to give the JVM a kick in the ass doesn't hurt..

 

[Eniko]

The most beautiful language to the computer is assembly, which is also beautiful to most programmers I think.
How are you defining beautiful in the context of assembly being beautiful to most programmers? Because I have a feeling most programmers wouldn't agree to this so readily.

Also this thread has made me think. If Java outperforms CPython, then what about Jython?

 

[bzar]

The most beautiful language to the computer is assembly, which is also beautiful to most programmers I think.
How are you defining beautiful in the context of assembly being beautiful to most programmers? Because I have a feeling most programmers wouldn't agree to this so readily.

Also this thread has made me think. If Java outperforms CPython, then what about Jython?

I'd say two very important factors for language "beautifulness" for me are:

1. Powerful syntax (little code makes a lot of functionality, "more bang for the buck")
2. Readable syntax (most code can be understood by novices on statement level without explanation, also read quickly by veterans)

There are others, but these just popped into mind. Many languages try to balance these two. Assembly does not do either very well for obvious reasons. Python, on the other hand...

 

[Kramy]

Java on x86 is incredibly fast - perhaps even faster than C, in some cases.

I'm not an expert, but this seems false.

Why? Because C is so incredibly fast that nothing could ever be faster in any circumstance? :blink:

http://www.stefankrause.net/wp/?p=9

Unfortunately, that article hasn't been updated to include j6u11, which is quite a bit faster than j6u2.

http://shootout.alioth.debian.org/u32q/ben...&lang2=java (using old JRE)

http://bytonic.de/html/benchmarks.html (using old JRE)

Java is usually slower than very-well-coded C - but not by much. Certainly not enough to discourage using it. The memory usage is the bigger concern.