The Timberwolf-version is probably one with debugging info.
So, if anything, the debugging-version could be slower...?

Other that that, I assume you can just replace the file in Sys:SObjs/ with the one from the Timberwolf archive. (Although it isn't recommended.)

Cool! How did you do it?

I was aiming for creating a Hollywood presentation for work (coincidentally regarding a course aimed for research students on Information Visualization and Retrieval!). But I ended up doing it in impress.js (a javascript library for Prezi-like presentations), since I didn't have enough time to learn Hollywood.

Do you have fixed layout, or is it possible to dynamically change layout after slides have been written?

Great article! This is the kind of information we need!

Quote:

You can use Chris Youngs addr2line-ARexx.-script: http://aminet.net/package/dev/debug/addr2line



This should get you the correct sourcefile and line.

@Raziel
Its going slow. At the moment its just me, but Thore is working on MorphOS, and Chris is an OS3 resource. I am hoping to get some more done, but after new year I'm starting a new project at work and will probably not have much good brain activity after work.

I try to post stuff in the blog whenever there is anything (or nothing) to report: http://jamiga2.blogspot.com/

Quote:
GUI yes, file I/O no. I guess it would be possible to have a local server that receives data to write a file to disk, but JavaScript in a browser cannot natively write to disk. It could be possible to use the mozilla spidermonkey library which exists for OS4. But that's outside the browser environment.

Indeed cool.

However, as the developers say, its more a proof of concept. In its current state I'm guessing it is of no more (but rather less) use than JAmiga. Furthermore, since it lives in the JavaScript universe, AmigaOS-specific stuff wont be usable (i.e. ReAction/MUI, file I/O, etc), atleast not without an Amiga specific class library. But then again, if it was implemented by using the DOM tree and regular HTML forms it would be possible to get some sort of GUI support. JavaScript in the web browser context cannot interact with the desktop in any way, i.e. open files and such. (If I understood right, the dev mentioned that the minor file I/O used, was handled outside the web browser context.)

One could possibly use Spidermonkey JavaScript available on os4depot, if OWB's JS lib is not possible, and adapt to some hooks to Amiga... but that's basically what's currently going on with JAmiga.

I don't mean to sound negative, its really a cool project. But it won't magically make Java fully function on Amiga. Not yet atleast.

I couldn't find any jar-file on their webpage, but if it's only text based, and does not use any to advanced stuff in Java, it should run. Its certainly an interesting program to use as a test-case for a non-GUI enabled JAmiga version.

Moreover, the link pointed me to a "Retrotranslator" which might be used to enable post-java 5 programs to work. Needs a closer look... :)

Quote:
Isn't there an issue when working with threads, or rather processes, and throwing exceptions? I might be wrong though, just remember something like this, perhaps is was the static linking I'm confusing it with.

If I do anything about the toolkit, I will do it in ReAction. Mostly since I don't know MUI.

As stated, classpath work has to be done anyway, irrelevant of VM used. Both JAmiga and JamVM uses GNU Classpath. JamVM also has support for OpenJDK, and new stuff in JAmiga classpath aims at being OpenJDK "compatible".
Either way, the actual work can be re-used, if not used right away.

Regarding QT and other APIs, those are possible. One GUI toolkit in GNU Classpath uses QT. But, given that some GUI toolkit functionality is already implemented in JAmiga in Gadtools, it is actually easier to work with that. And I personally would like Java on Amiga to be truly Amiga. We're discussing on implementing a MUI toolkit, since that allows us to use it with AmigaOS4, OS3, Aros and MorphOS.

I looked at JamVM, and got it to compile, but never run.

As billt says, most work is needed for the classpath-libraries. So, at least in theory, it would be possible to use the same classpath for both JamVM and JAmiga.

Given that JAmiga works today, I have chosen not to put more effort in JamVM, but instead focus on the classpath stuff. Currently this is GNU Classpath, but I am looking at OpenJDK aswell, and for new stuff I try to use the same approach as they have in OpenJDK. The GNU Classpath is said to be abandoned, since we now have the OpenJDK.

Here I am!

And time has been limited after my vacxation, so no new work has been done. But I haven't abandoned the project. I will try to make more regular updates, even when there is nothing to update. The plan is to make a more detailed plan.

My effort is not in any way correlated to bounties -- more money won't give me more time. Unless there is a bounty for hours per day. :)

I'll try to answer any questions. I have also gathered some questions at the Jamiga2 project page, but they're not very technical.

Jamiga can simplified be said to consist of two things:
* The JVM, Java Virtual Machine. This handles execution of the compiled Java programs, the bytecode.
* Class libraries. The class library is what builds up Java. These are all the standard Java classes for handling lists, threading, file I/O and other standard stuff. Jamiga uses the GNU Classpath class libraries, and we're also looking in to using Oracle's OpenJDK.

What is a Java program?
A Java program consist of class-files, files with bytecode instead of machine code. Class files can be run by issuing a command like
java HelloWorld
This will start a Java Virtual Machine process, that tries to find a class named HelloWorld.class with a main-method to run (much like C's main-function).

Java applications usually come packed in so called JAR-files. This is basically zip-archives that contain several class files. The aim is of course that these Jar-files can be double-clicked and started like any Amiga program.

So Java program does not have a single .exe-file -- rather they have class files run by the main Jamiga executable, "java". These class files are the same, no matter where they are run, be it AmigaOS 4, MorphOS, Aros, Windows or MacOS.

What does Jamiga's java.library do?
The java.library and Jamiga's other libraries (javanio, javanet, etc) are only for internal use by Jamiga. No other programs should use them. All Jamiga stuff could easily reside in one big executable, but the library usage is consistent with how the GNU Classpath is done.
The java libraries (java.library and so on) contain code that "hooks" the class libraries to native Amiga stuff (so called native methods). So whenever you in java do:
java.io.File = new java.io.File("myfile.txt");
a call is made to IDOS->CreateFile(); which reside in javanio.library.

How does graphics in java work?
GUI and graphics stuff is supported in the standard Java classes using what is called AWT (Abstract Window Toolkit). this contain classes for buttons and windows and such GUI stuff. There are also methods for primitives such as "draw me a line"-methods.
The current Jamiga AWT implementation uses GadTools and Intuition. We're currently looking at using MUI for this, since that is supported by all Amiga platforms.

There are also classes for OpenGL and sound stuff -- some of it is standard official JDK-stuff, and other is un-official. But basically its only a matter of writing native C code to create the necessary native methods.

What can Jamiga currently do?
If one were to try and run any of the games you suggest, it should preferrably not run with a "ClassNotFoundException", or just plainly crash.
Currently Jamiga supports threading, some AWT/graphics stuff, file I/O and upcoming network stuff. What's missing feature wise is sound support, some graphics stuff (can't say exactly what atm) and other low level/internal stuff.

If these games only require Java 1.4, the aim is to have them running. If they require 3rd party libaries, there is a bit more work to do. But once we get Java 1.4 running, 3rd party libraries is as easy/complicated as porting other applications.

Perhaps not very good answers. Its rather hard to tell what will work, and how much work it will be to get things to work. But it should be possible to get things running without for instance sound support, and only create empty native methods.

But I doubt that they will run without adding more stuff to Jamiga.

@kas1e:
Moved question (and answer) to separate thread here.

Moved here from here

Quote:
There is some GUI support in form of AWT stuff. Look at classpath examples for stuff that should work. No sound though.

Some work has been done since 0.0.6, but not much in regard to graphics or sound (i.e. nothing). But it'd be an interesting thing to try and make some real stuff work for an upcoming release.

The next release (0.0.7 or so) is planned, and will include a few basic stuff like jar-loading, MOS and AOS3 support, networking, which is mostly done already. Following version will hopefully add some content, and a game would certainly be good content.

Do send an e-mail to the Jamiga mail group and perhaps we could collaborate.

Quote:

You're much welcome to join the Jamiga-project!

It is still active, and we're planning on a new release -- although still beta.

There a few simple examples in the OS4 SDK.

How about patching IDOS->System with a function that records each application's arguments? So when you need it it's already stored in an array.

@salas00:
Nor should I do new. The autodoc gave me the impression that it should be a pointer to a MsgPort, when it really should be a pointer to a pointer. So I wound up trying lots of different things.