So, a new update available. The main part being AmiUpdate support.

http://jamiga2.blogspot.se/2013/08/jamigaupdate.html

I thnik we are closer to NetBeans, since NetBeans uses Swing, where Eclipse uses SWT. Swing is part of the Java standard, and SWT is not. Both require some amount of native stuff to be implemented, and Swing (and AWT) are supported in GNU Classpath, but SWT would be implemented beside this.
I think this is mostly true, I haven't looked into SWT much though.

Thanks for all the nice comments!

I've received a few bugs (thank you Joeled! :) ) regarding some missing protection bits on the "java.script" file. It should have the "script" attribute set. If it doesn't you can fix it by running:
"protect JAmiga:java.script +s"

Also, I seem to have hard coded a path to my own system. A request for volume "Filer:" might come -- if so, just assign it to ram:, and it should work without it.

As for AmiUpdate; it is planned. But I haven't looked into it more closely. Hopefully the next release.

So, I've made an archive with the latest JAmiga release.
Its kind of beta state. I've tested it on my XE and X1000, and it works ok.

See the blog for details and downloads: http://jamiga2.blogspot.se/2013/07/a-silly-release.html

I say its a silly release, mostly because we haven't got much to run on it (since GUI support is lacking). But its pretty much what milestone 1 was all about.

Quote:
Perhaps it'd be a good idea to set up a real collaboration effort with open SVN and stuff, to allow more people to contribute.

Its hard (and boring) to did it after you've successfully compiled and built/ported something. Often you tend to do a bit here and there locally, and then stumble upon a configuration that works, but is highly dependent on your local configuration. A real effort that aims for collaboration would be ideal.

Quote:
What kind of license has OWB got? If its the most free variant, I'd guess it'd be out right wrong to keep them closed.
But I assume its one of those where you can add closed source modules and use the rest as-is.

Edit: It seems to be BSD, so ok to keep it closed.

Quote:
JamVM has PPC JIT already, so in the best case it should be enoguh to enable a flag in config.h. My plan is to get thefirst usable beta out of the way, and finish the bounty. Then I'll look into stuff like JIT, see what kind of other important applications we don't have that will work with the current version has support for. Swing and AWT is, I fear, a rather big thing to get done. I should be able to use QT, I think. As for AWT, its relatively seldom used, and we'd actually be better of with something like SWT which is used in Eclipse and NetBeans IIRC.
Furthermore, before putting huge amounts of efforts into GNU Classpath, I'd prefer to focus on OpenJDK,which would give us Java 8 amd beyound, where GNU CP only has Java 5, and development is low (much due to OpenJDK).
Any work done on JamVM and JIT benefits both OpenJDK and GNU CP.

Quote:
Don't keep your hopes up on the first version though...

I'm going to disable my very slow debug outputs, but it still is the ordinary interpreted version compiled in. Haven't touched the JIT or looked at any of the other optimizations available. But in coming version I will of course see into that.

I just have to share this tweet with you:
https://twitter.com/jaokim2001/status/347070288384634880

There's more than just the 140 characters...

I believe you can up the sweden count by one, I at least count to four of us.

The danes can have their ESC win, it's so last year... We've moved on to the more valuable X1000 lead.

You can add my name to the list.

One thing to notice about the netfs from aminet, is that you need to manually set the executable flag to the service. At least I had to do that.

Other than that it works for moving files in Workbench, but not reading using Multiview or Notepad, and more. It works with applications such as Cubic IDE, but in the other cases DOS complains about unsupported packet or something. I'm guessing something with newer DOS calls?

Ah, yes, that's problem number 2. Being able to run it from a browser. I naïvely thought of iBrowse, remembering it should be possible to create an NPAPI library and make it work. But iBrowse of course has other limitations... I dont know about OWB, but Timberwolf surely must have NPAPI possibilities?

I've also run applets in an applet runner, when I actually managed to put a poor old web applet under automated tests for a bank. (The applet wasn't used for login, but rather file upload.) So, I guess the applet could be made to run, but what it does regarding security I'm not really sure of.

I do however think that with a NPAPI compatible browser we'd be good to go. Even if the Java applet perhaps would open up in a separate window. But, I really don't know for sure.

Quote:

In milestone 3, Java applet support is planned. And I believe that should be enough for those bank that use applets. I don't know if the banks put up some other restriction, but I really don't think so -- it should be standard Java. Someone whose bank uses a Java applet could try it with JamVM and GNU Classpath under Linux in order to know for certain (or if someone could point me to a link where I can test browser capability, I could test it on my JamVM installation). When we get to milestone 3, I will try to gather as much information as possible in order to define exactly what is expected work, and what might not work.

But for milestone 1, no. No applets, no GUI, no graphics.

And, just for the record, when milestone 1 is done, milestone 2 and 3 should be more straight forward.

Quote:
It was actually only a snapshot of my desk at the time. Although the chocolate bar wasn't entirely chosen at random. :)

I just treated myself a chocolate bar and a coffee, you can read all about it at the Jamiga2 blog: Coffee and bounty.

The bounty for Java milestone 1 is hereby open: JAVA - (Milestone 1) JVM for AmigaOS.

(Sorry for cross-posting.)

@ChrisH: Yes, more documentation on the inner details of the pthread implementation would be needed. More specifically how signals are used/handled.
[Pseudo-technical ramblings will follow]

The pthread library for instance lacks pthread_sigmask(). (pthread_sigmask() is supposed to tell us which signal the pthread responds to. The same thing that sigprocmask() does for an entire process). I assume this is due to the way Amiga processes work, compared to how pthreads work. As I understand it, each pthread is in the Amiga implementation mapped to an Amiga Process. Each Amiga Process can be signalled on its own, whereas in the "real" pthread world, i.e. Unix/Linux, a pthread is more a "side track of execution" within its starting process, and not a separate child process. In a pthreaded program, it isn't possible to signal one specific pthread from a user perspective, you rather send the signal to the entire process, which then, through pthread_sigmask, decides if a pthread should handle it.

The reason for not having a pthread_sigmask, might be that we don't have a sigprocmask() call either. Or, we have it in clib2, but not in newlib. Perhaps it just wasn't possible to implement pthread_sigmask(), without knowing exactly how sigprocmask() is implemented, and trying to mimic that behvaiour in newlib. But I'm just guessing.

Anyhow, in JamVM we have a Signal Handler pthread, which should take care of any signals sent to JamVM (i.e. Ctrl-C and such). But in the Amiga implementation, this Signal handler is really just a child process to the main JamVM process, and signals sent to the main process won't reach the Signal Handler -- at least not without some manual signal proxying "magic".

I might have been able to use the pthread implementation, and just made my own pthread_sigmask. But given I needed som signal proxying magic, I need to hook those bits in together with all the other pthread calls. And furthermore, I don't really know what kind of signals the pthread implementation uses, if any.

Blah blah blah blah.
[/Pseudo-technical ramblings end here]

I'm not really one hundred percent sure of all my claims above, but I can at least for certain tell you that I now finally managed to get a "Hello World" running using JamVM. There are a few more details in the JamVM engine to tend to, but I should be able to continue the real work on integrating the Amiga stuff, more specifically networking.

I *think* a listbrowser can only contain either text or boopsi objects based on the image class (as set by LBN_Text and LBN_Image, respectively).
I guess fuelgauge doesn't extend image?

If you find a solution I'd be all ears, though.

@billt

Good question! JamVM is a virtual machine, just like JAmiga. So JamVM replaces JAmiga.

Then there is the class library which need to be adapted to Amiga stuff, such as using bsdsocket.library for network stuff (which I have started on for JAmiga and can re-use), file I/O, and GUI. Basically, with me moving to JamVM, I can focus on Amiga-specific stuff, and not re-implement what has already been done in JamVM.

Another possible way to think of: JamVM/JAmiga is the CPU, and the class library is the OS. Sort of.

I'm a bit giddy and happy! I have from time to the other been working on JAmiga. Today, I however lost encouragement. With JAmiga.

However, still determined to get Java to Amiga, I persuaded my previous JamVM path. And have made success!

Me and kas1e have previous discussed a strange relocation error which revolved around elf.library shouting out a requester about "Unsupported reloc". Kas1e found quite a lot of information, which I have tried with, to minor avail. Today, I however searched some more, and tried some other things.
The solution was easy: first, do everything kas1e suggest, i.e. remove any TLS stuff. And then, what I found out by chance, you need to remove all "__thread" definitions you might have left in your code. They hsould be within #ifdef HAVE_TLS, but I had one spare lying around. And with that removed, the relocation error disappeared. So, I now have a JamVM crashing! Which is great!

Some background info on the TLS stuff. TLS stands for Thread Local Storage, and is a way for multi threaded programs to store thread local data. Basically, if you want a global object available for your thread, you can't use a static variable, since that will be shared by all threads. Introducing TLS, which relocates the memory dynamically by adding some non-standard elf-stuff. And this is controlled by the __thread keyword. A declaration "int __thread myVar;" is then defined as a thread local storage, and gets some special attention in our elf binary. Apparently, which kas1e found out, GCC from the Amiga adtools is built with TLS support enabled by default, so by just having a __thread keyword will trigger the elf magic -- which elf.library doesn't support.

So, to conclude, keep looking at the JAmiga blog, where I will post a new entry soon of my new JamVM progress.