WEBVTT

00:00:11.792 --> 00:00:15.712
Saturday the 19th September 2015

00:00:25.934 --> 00:00:36.101
Hi my name is Joakim Nordström, and I'm going to talk about 
Java for Amiga, which is my night time project.

00:00:38.131 --> 00:00:41.687
At daytime I'm a system developer at Telia here in Uppsala

00:00:42.237 --> 00:00:49.454
and at night time I'm trying to get java to work on the Amiga

00:00:52.944 --> 00:01:03.594
The project I'm working is called JAmiga, and I have continued on
an open source project from 2003-2005

00:01:04.144 --> 00:01:10.823
It was started by two Germans, Peter Werno and Andre Dörffler.

00:01:12.604 --> 00:01:16.749
They started creating Java for Amiga.

00:01:16.749 --> 00:01:23.089
and released a version in 2005, and then nothing much happened
until around 2009 when I began looking at it.

00:01:25.084 --> 00:01:30.574
At that time they supported parts of Java 1.4.

00:01:32.460 --> 00:01:38.023
If you know something about Java, you'll get something from this,
and if you know nothing about Java, I hope you'll also get something out of this.

00:01:39.063 --> 00:01:44.999
So hopefully everyone will be happy at the end, 
or everyone will be confused by my ramblings.

00:01:45.822 --> 00:01:52.281
The target architecture is Amiga, and I'm working at the next generation Amiga.

00:01:53.221 --> 00:02:00.915
So it isn't the classic Amiga as seen on the first slide I'm focusing, but rather the next generation Amigas.

00:02:01.385 --> 00:02:13.586
And, believe it or not, Amiga still selling some sort of computers, and then one I have is this with a Power PC processor.

00:02:13.586 --> 00:02:23.043
And if I'm not mistaken, this is the same processor Mac should've used, if they didn't switch to Intel.

00:02:25.659 --> 00:02:35.385
The operating system i s Amiga OS 4.1, the latest release.

00:02:35.854 --> 00:02:41.496
Audience question: can you run old Amiga applications on this new computer?

00:02:41.496 --> 00:02:53.658
Yes, yes you can, AmigaOS emulates the old Amigas, and can also take advantage of the updated functionality.

00:02:55.166 --> 00:03:02.361
Audience question: as an old Amiga user, have they fixed the biggest problem, that the entire file system was corrupted when the machine crashed?

00:03:02.377 --> 00:03:09.897
Yes, there are a few new file systems that aren't as sensitive.

00:03:09.897 --> 00:03:12.613
Audience question: Have they removed the Guru meditation?

00:03:12.659 --> 00:03:18.669
Yes, I'm sorry, they've replaced it with the Grim Reaper.

00:03:23.767 --> 00:03:28.745
So the guru is gone, but problems persist.

00:03:30.615 --> 00:03:39.975
I'm going to start by showing the parts in a typical Java
installation, so we'll get a common ground to start from.

00:03:41.345 --> 00:03:48.500
In essence, it's these four parts. And I'm going to go through them one by one.

00:03:50.566 --> 00:03:54.862
We'll start with the JVM.

00:03:56.224 --> 00:04:02.328
The java Virtual Machine is an executable file, usually java.exe.

00:04:02.328 --> 00:04:18.867
It execute bytecode, and bytecode is the JVM's internal instructions, 
just like an x86 processor has x86 instructions, and PPC has PPC instructions.

00:04:18.867 --> 00:04:24.367
The JVM translates from bytecode to processor instructions.

00:04:24.367 --> 00:04:33.313
In the most simple case, it's relatively easy. 
One instructions have its obvious counterpart.

00:04:33.313 --> 00:04:37.418
Sometimes one bytecode is several processor instructions, and so on.

00:04:37.448 --> 00:04:41.391
It is however a rather slow process, if you take the easy way.

00:04:41.391 --> 00:04:47.483
If you want more a advanced JVM, you have to do various smart things.

00:04:51.579 --> 00:04:56.989
The JVM also handles memory and that stuff.

00:05:00.174 --> 00:05:04.583
Going right we come to the class library.

00:05:05.594 --> 00:05:10.710
And this is basically the Java SE standard.

00:05:10.710 --> 00:05:16.322
The class library are the standard classes you use when youäre developiong Java programs.

00:05:16.322 --> 00:05:21.581
And it's basically Oracle that decides how this should look.

00:05:22.832 --> 00:05:30.997
And if you know your Java, you recognize all the standard classes, in the java packages.

00:05:31.413 --> 00:05:40.690
This is stuff like handling lists, writing to the console, 
open files, and, handling XML and various things.

00:05:44.797 --> 00:05:51.132
In order to for instance open a file, we need to somehow get 
access to the underlying operating system.

00:05:51.689 --> 00:05:55.319
For this we have the native library.

00:05:56.598 --> 00:06:04.401
And this is the way from the class library, which is the same for all JVM's,

00:06:04.401 --> 00:06:11.220
but the native library is different, depending on the operating system.

00:06:11.220 --> 00:06:19.742
When we're on Windows, the native library is a DLL, Unix/Linux uses shared objects, and on AmigaOS its library files.

00:06:22.690 --> 00:06:27.182
And this is basically the parts we have in a JVM.

00:06:28.599 --> 00:06:34.782
And now I'm going to show what alternatives we have for these parts.

00:06:35.301 --> 00:06:41.837
The class library and the native library are closely tied together.

00:06:42.131 --> 00:06:57.959
And there is in essence two choices: OpenJDK from Oracle, and GNU Classpath.

00:06:58.038 --> 00:07:04.523
Open JDK supports the later Java versions 7, 8 and 9.

00:07:06.425 --> 00:07:11.264
In the beginning OpenJDK wasn't "Open"

00:07:13.941 --> 00:07:31.573
Somewhere between Java 6 and 7 that Sun decided to open up JDK and make it open source.

00:07:32.751 --> 00:07:37.981
Before that, around 1998 the JDK was still closed source.

00:07:37.981 --> 00:07:46.429
And then some people started GNU Classpath, which is an open source version of the Java standard.

00:07:46.429 --> 00:07:53.453
They implemented everything in the Java standard from scratch.

00:07:53.453 --> 00:08:01.315
And when OpenJDK became Open, people stopped developing for GNU Classpath.

00:08:01.352 --> 00:08:06.131
A lot of people who started with GNU Classpath, are now developing for OpenJDK.

00:08:06.131 --> 00:08:09.727
Some work at Oracle, and some develop in their spare time.

00:08:16.913 --> 00:08:18.608
A few different JVM options

00:08:19.389 --> 00:08:25.912
What you're probably using today is Oracle's hotspot,

00:08:25.912 --> 00:08:31.965
which is, if I'm not mistaken, a combination of JRockit and HotSpot.

00:08:31.965 --> 00:08:39.929
JRockit is actually a JVM developed by a Swedish company, later bought by Oracle.

00:08:39.929 --> 00:08:47.669
Some of the JRockit developers are like working a t Oracle now.

00:08:49.060 --> 00:08:53.910
Microsoft and MacOS had their own JVMs up until 2001.

00:08:53.910 --> 00:09:00.561
Or rather, Windows had its to 2001, and Mac had its until OSX.

00:09:01.430 --> 00:09:04.571
But then they skipped them, and let people decide themselver

00:09:04.903 --> 00:09:08.584
Then we have onw called "Kaffe".

00:09:08.834 --> 00:09:13.863
Its open source, and it support GNU Classpath

00:09:13.863 --> 00:09:19.315
It also exists for Classic Amigas, i.e. the 68k processor.

00:09:19.315 --> 00:09:30.973
The Jamiga project also has it s own virtual machine, which also can run on Classic Amigas.

00:09:31.329 --> 00:09:37.082
Then there's a nother variant, GCJ, GNU Compiler for Java.

00:09:37.082 --> 00:09:45.198
Which compiles either java code, or bytecode, to machine dependent code.

00:09:45.198 --> 00:09:50.936
So the bytecode is translated to x86 or PPC code.

00:09:50.936 --> 00:10:00.394
So you get a binary which needs to be compiled for each new architecture.

00:10:00.394 --> 00:10:05.656
Then I can also mention Dalvik which is Android's VM.

00:10:05.656 --> 00:10:14.349
And there's a small dispute, if Dalvik isn't in fact JamVM, where 
Google took the JamVM code and called it Dalvik.

00:10:15.202 --> 00:10:20.774
But, lets focus on this VM JamVM.

00:10:21.532 --> 00:10:29.898
It's developed since 2003, written in C, with some assembler.

00:10:29.898 --> 00:10:34.195
It uses Posix threads, and it supports PowerPC.

00:10:34.218 --> 00:10:38.955
So I thought this was good and interesting.

00:10:39.649 --> 00:10:43.883
So instead of continuing JAmiga's VM, I began looking at using JamVM.

00:10:44.338 --> 00:10:46.440
And that is what I've done.

00:10:47.357 --> 00:10:54.875
In teh beginning it only supported GNU Classpath, but then when OpenJDK became open, it supports that aswell.

00:10:55.418 --> 00:11:02.157
So when I'm developing, I'm porting JamVM.

00:11:04.071 --> 00:11:10.121
A small summary. 
The JVM is JamVM

00:11:10.547 --> 00:11:18.602
The class library is GNU Classpath, since that is what original JAmiga supported.

00:11:19.154 --> 00:11:21.079
So I've continnued with that.

00:11:21.353 --> 00:11:25.680
Native libraries are .library, and operating system AmigaOS 4.1.

00:11:31.923 --> 00:11:40.492
I can talk a bit about the interface of GNU Classpath.

00:11:41.115 --> 00:11:45.695
From the class library, via the native library down to the operating system.

00:11:45.695 --> 00:11:50.018
And there's a number of different native libraries.

00:11:50.018 --> 00:11:53.542
And these libraries corresponds to the Java packages.

00:11:53.542 --> 00:12:02.704
Comparing this with OpenJDk, they have one big library for all classes

00:12:02.704 --> 00:12:11.644
A small screen shot over GNU Classpath file structure.

00:12:11.644 --> 00:12:17.729
On the right side we see the Java standard class "java.lang.System".

00:12:17.729 --> 00:12:21.507
This has some connectiosn down to the operating system.

00:12:21.507 --> 00:12:25.287
And those connectiosn can be found in the "java.lang.VMSystm" class.

00:12:25.287 --> 00:12:28.337
And that is a pretty nice connection.

00:12:28.337 --> 00:12:38.854
If we have a Java class, wee know which native class we should look in,
to find connections to the OS.

00:12:38.854 --> 00:12:47.016
In OpenJDK it isn't quite as nice, but I think they're trying to achieve that.

00:12:48.201 --> 00:12:53.116
And now we're going to run some Amiga.

00:12:53.116 --> 00:12:59.797
I'm going to show how it looks when you run a Java program, and what happens in the Java code.

00:12:59.797 --> 00:13:03.313
So, now there's going to be some code.

00:13:03.313 --> 00:13:06.957
Here we have a small Java program.

00:13:06.957 --> 00:13:12.668
And here we have a main method that will print to the console "Hello Uppsala".

00:13:12.668 --> 00:13:16.392
I.e. "Hello World" in Java.

00:13:16.392 --> 00:13:22.494
And we're going to see what happens "under the hood".

00:13:22.494 --> 00:13:24.840
Audience question: is your laptop an Amiga machine?

00:13:24.840 --> 00:13:25.773
No.

00:13:25.773 --> 00:13:28.008
No. Its an Ubuntu.

00:13:28.008 --> 00:13:30.589
The amiga is at home, it's to big to take with me.

00:13:30.589 --> 00:13:36.469
So this is just pictures.

00:13:36.883 --> 00:13:43.824
We begin here in "Java.lang.System"
"System" is a class in the java standard.

00:13:43.824 --> 00:13:47.265
And then we have an object "out" here.

00:13:47.265 --> 00:13:53.760
And if we go to the System class, we'll find that "out" is a PrintStream.

00:13:53.760 --> 00:14:01.478
And if you know your Java, you know that PrintStream has a method "printline",
which print a line to the stream.

00:14:01.478 --> 00:14:09.455
Then we need to look at what "out" is initialised to.

00:14:09.455 --> 00:14:15.078
And then we see this VMSystem class, which has a method "makeStadnardOutputStream".

00:14:15.078 --> 00:14:20.096
So we move along to that class.

00:14:20.096 --> 00:14:29.840
And now, this is VMSystem. I.e not a Java standard class, but a aprt of Gnu CLasspath..

00:14:29.840 --> 00:14:34.419
And here we have a method "makeStandradOutputStream"

00:14:34.419 --> 00:14:40.045
This returns a PrintStream, which wraps around a BufferedOutputStream
that wraps around a FileOutputStream...

00:14:40.045 --> 00:14:45.475
If you know your Java, you know about these streams... 
but we'll ignore that for now.

00:14:45.475 --> 00:14:50.165
The main thing here is the "FileDescriptor.out".

00:14:50.165 --> 00:14:53.772
This is just ordinary Java code.

00:14:53.772 --> 00:14:56.724
But this "FileDescriptor.out" is a bit interesting.

00:14:56.724 --> 00:15:01.601
So we move on that.
We end up in a new class: "FileDescriptor"

00:15:01.601 --> 00:15:05.398
And that has an object named "out" up there.

00:15:05.398 --> 00:15:14.973
And.. that is a FileDescriptor object, which has an 
parameter FileChannelImpl.out, again.

00:15:14.973 --> 00:15:18.832
So we move on to the class "FileChannelImpl".

00:15:18.832 --> 00:15:25.697
And there we find the object "out", somewhere... 
There!

00:15:26.977 --> 00:15:31.718
And if we look here; here we load our library "javanio".

00:15:31.825 --> 00:15:41.315
So when this line is executed we're going to open "javanio.library".
If this was Windows, we would've opened "javanio.dll".

00:15:43.858 --> 00:15:46.140
We continue with "out".

00:15:47.263 --> 00:15:53.514
Down here we see "out=ch". 
And "ch" we previously set to a FileChannelImpl.

00:15:53.514 --> 00:15:59.359
Which is wrapped around a "VMFileChannelImpl.getStandardOut()".

00:15:59.359 --> 00:16:05.658
So we move along to the "VMFileChannelImpl" class

00:16:05.658 --> 00:16:10.390
And then we see the method "getStandardOut()"

00:16:10.390 --> 00:16:16.584
And that methd is here "getStandardOut",
which return a new VMFileChannel

00:16:16.584 --> 00:16:25.851
And calls a method "stdout_fd",
which is here, and it has no method body...

00:16:25.851 --> 00:16:31.839
However, it has a intereseting word here: "native"

00:16:31.839 --> 00:16:37.551
This means, that this call will be made to some sort of native library.

00:16:37.551 --> 00:16:42.183
And now we will go from Java to C.

00:16:42.183 --> 00:16:47.593
So this is C code.

00:16:47.593 --> 00:16:53.712
And this is the function that is executed when we call this native method.

00:16:54.786 --> 00:17:01.106
And, now,m if you know your Amiga,
you might recognize this "IDOS->Output()".

00:17:01.106 --> 00:17:07.868
This is a C function in Amigas SDk, which returns a pointer to the console.

00:17:08.424 --> 00:17:15.733
So the pointer to the console is returned into the Java code,
and going all the way back...

00:17:16.174 --> 00:17:29.669
So, somewhere here in the System.out, there is a small pointer to our C function.

00:17:33.214 --> 00:17:38.493
So this is some explanation to why Java is a bit slow to start up.

00:17:39.516 --> 00:17:50.543
Aroudn 1995-1996 it took a long time to start a JVM,
since all these classes had to be loaded on start-up

00:17:52.420 --> 00:17:58.352
It is also a bit hard to find errors, when you don't know where you are.

00:17:58.860 --> 00:18:05.040
This call.... er... eh

00:18:05.647 --> 00:18:13.539
This call, from Java code to C code,
looks a bit magic.

00:18:13.539 --> 00:18:19.249
And it is a bit magic, 
but not much.

00:18:19.277 --> 00:18:29.814
How does the JVM know which native method it should find?

00:18:30.487 --> 00:18:39.295
From out antive libaray we can export different functions.

00:18:39.295 --> 00:18:51.666
In the Java standard, it is defined that all native 
functions will have a standard name,

00:18:52.231 --> 00:19:00.369
with a prefix, followed by the java package, method name and arguments,
so the VM can find the method.

00:19:02.580 --> 00:19:13.564
And with these small header definitions in the C code,
the compile knows that these functions should be exported

00:19:15.142 --> 00:19:18.751
But this is not how it works on the Amiga.

00:19:18.751 --> 00:19:26.700
In the Amigas native libraries we only export on function "getLibraryContent"

00:19:26.700 --> 00:19:33.977
And that returns a strcture where the JVM can do the lookup.

00:19:34.555 --> 00:19:44.149
So that is one difference in Amiga.

00:19:46.132 --> 00:19:49.438
Then ,some more code.
A different example.

00:19:49.803 --> 00:19:54.498
We're going to look at the class VMSecureRandom.java

00:19:55.784 --> 00:20:00.210
The VM prefix tells us that there might be antive calls in here.

00:20:00.833 --> 00:20:11.712
And this class generates a random seed,
which is used by f.i. cryptography.

00:20:13.578 --> 00:20:21.775
And one of my users that tested Jamiga,
found a small crypto library

00:20:21.775 --> 00:20:22.296
However, when executing it, the entire machine locked up.

00:20:28.256 --> 00:20:35.694
And this is the VMSecureRandom class.
The detalis aren't important.

00:20:35.694 --> 00:20:40.651
But here we have the method "generateSeed",
that generates our seed.

00:20:40.651 --> 00:20:44.309
It does this by starting 8 threads that spins,
and increments a counter,

00:20:44.309 --> 00:20:50.282
and then randomly they will end,
and then we'll end up with a random value.

00:20:50.828 --> 00:21:01.106
And it was here that JVM started 8 threads, got into a (unsolved) race condition.

00:21:01.106 --> 00:21:06.952
however, I managed to shorten this method to this.

00:21:06.952 --> 00:21:12.290
Here we instead open a file from the Amiga device "Random:"

00:21:12.290 --> 00:21:20.273
Which generate random numbers.

00:21:20.273 --> 00:21:24.112
So, this method became much shorter, and a lot faster.

00:21:25.532 --> 00:21:38.597
As an example we have here a variant from a Unix flavor,
wirh a native call to his C code.

00:21:40.799 --> 00:21:50.201
And this is C++, which with its object orientation maps a bit better to Java.

00:21:51.247 --> 00:21:55.335
And just for the fun of it, we can look at the Win32 variant.

00:21:55.335 --> 00:22:01.690
And this just throws an exception, that this 
method isn't supported on Win32.

00:22:03.361 --> 00:22:08.842
Oh no! The Guru meditation!

00:22:09.221 --> 00:22:12.514
Not at all planned.
Oh no. How annoying.

00:22:12.514 --> 00:22:20.049
Another problem i had,
was how these threads are handled.

00:22:20.049 --> 00:22:30.126
I experienced some problem when adding network support

00:22:31.563 --> 00:22:37.650
I started a Java program
which opens a socket

00:22:38.564 --> 00:22:43.397
And this socket should talk to some other server, and send data to it.

00:22:43.855 --> 00:22:53.631
And I thought it might be nice to put in its own thread,
so the main thread can do other stuff.

00:22:54.373 --> 00:23:00.214
We create a socket,
and a new thread.

00:23:00.978 --> 00:23:06.002
And then I try to read from the socket here.

00:23:07.068 --> 00:23:13.879
But then I got this error:
apparently, the socket, isn't a socket!

00:23:14.744 --> 00:23:16.433
Much strange.

00:23:21.238 --> 00:23:25.079
But if you read the Amiga docs...

00:23:25.079 --> 00:23:33.461
You'll find that this socket 
only exists within this process.

00:23:33.461 --> 00:23:42.276
There are ways to circumvent this,
they are bit troublesome.

00:23:42.565 --> 00:23:51.999
So instead I here created a 
new socket process.

00:23:51.999 --> 00:24:01.042
So instead of sending the socket ID, I instead send 
a reference to the process.

00:24:01.296 --> 00:24:17.365
We'll continue with these threads.

00:24:18.094 --> 00:24:24.607
I mentioned that JamVM uses Posix-thread,
where AmigaOS has processes.

00:24:25.130 --> 00:24:38.501
Posix-threads are a bit more lightweight than AmigaOS' processes.

00:24:38.501 --> 00:24:46.241
The AmigaOS processes has a few connections to DOS library and such.

00:24:46.241 --> 00:24:52.201
Audience question: do they still have all that old DOS stuff, like BCPL and processes.

00:24:52.453 --> 00:24:55.298
It's sort of all gone in Amiga OS 4.

00:24:55.298 --> 00:24:58.713
Audience: they had these heavy processes, and then "threads".

00:24:58.713 --> 00:25:02.855
Ah, yes, yes, that's still there.

00:25:02.855 --> 00:25:15.851
An AmigaOS process is a "task", which is more lightweight.
But the Amiga process has connections to DOS.

00:25:15.851 --> 00:25:28.461
And the "tasks" can't be used for disk I/O, so if you need that, you need a "process".

00:25:32.873 --> 00:25:43.738
Here we've started a simple Java class, "Start thread", that actually doesn't start a thread.

00:25:45.273 --> 00:25:49.502
We're going to see how this looks when its running on the Amiga

00:25:50.263 --> 00:26:09.232
Each new JVm instance, has beside the main process,
also have three JamVM specific Amiga processes.

00:26:09.232 --> 00:26:12.686
We have a Reference handler, Finalizer, and Signal handler.

00:26:12.686 --> 00:26:23.193
Reference handler handles garbage collection, i.e. frees created objects.

00:26:23.903 --> 00:26:29.855
The Finalizer runs the "finalize()" method on objects that's been garbage collected.

00:26:30.265 --> 00:26:34.288
And the Signal handler handles signals sent to the program.

00:26:35.310 --> 00:26:38.863
So it kind of looks like this.

00:26:39.800 --> 00:26:48.877
And now I'm going to end this, 
so why not try and end this Java program by pressing Ctrl-C.

00:26:48.877 --> 00:26:53.020
Ctrl-C is handled by the signal handler.

00:26:57.337 --> 00:27:06.415
And when it gets the Ctrl-C it executes the Java method System.exit and VMRuntime.exit().

00:27:06.415 --> 00:27:12.124
And then it also executes the native c-function exit().

00:27:12.124 --> 00:27:22.473
The problem with running exit(), is that only the Signal handler process is ended.

00:27:23.836 --> 00:27:28.014
Like i said, Amiga processes are a bit bigger than Posix-threads.

00:27:28.289 --> 00:27:35.462
If this was Posix-threads, an exit() would've ended the main process,
which would've ended the Posix-threads aswell.

00:27:35.928 --> 00:27:38.458
But not in the Amiga case.

00:27:39.377 --> 00:27:45.285
So instead, we run the Java methods in the Signal handler.

00:27:45.285 --> 00:27:49.677
And then we send the Ctrl-C signal back to the main process.

00:27:51.254 --> 00:27:58.941
Receiving that signal, the main process ends the three subprocesses,
frees memory,closes libraries, and then exists.

00:28:01.627 --> 00:28:04.942
And with that, I'm almost done.

00:28:06.039 --> 00:28:13.803
Current status: Jamiga is at version 1.2, downloadable from http://www.os4depot.net.

00:28:15.709 --> 00:28:19.833
There's also a few automatic updates available.

00:28:20.331 --> 00:28:29.648
Somewhat completet support for Java 1.5,
however no graphics or AWT.

00:28:33.851 --> 00:28:40.634
I also have a small Twitter client,
which uses Twitter4j.jar

00:28:41.659 --> 00:28:48.737
Its very simple, this is a command line tool you can run,

00:28:48.737 --> 00:28:52.352
which creates a small tweet.

00:28:52.352 --> 00:28:56.427
Fantastic! The technology moves forward, even for the Amiga.

00:28:57.476 --> 00:29:02.478
The plan ahead is to support OpenJDK

00:29:02.892 --> 00:29:11.178
And this a small test i ran, which shows that I'm missing java.libraray,
which I must implement.

00:29:12.113 --> 00:29:17.194
JamVM supports OpenJDK, out of the box.

00:29:18.636 --> 00:29:23.915
I'll also try to fix graphics stuff.

00:29:27.339 --> 00:29:32.124
Just to mention a few ways to build OpenJDK.

00:29:32.475 --> 00:29:38.618
You can either build it like Oracle wants you to.

00:29:39.032 --> 00:29:49.735
One though I had was to build OpenJDK, grab the class files, and then just iteratively see what's missing.

00:29:50.574 --> 00:30:03.665
Alternatively, you can build it using IcedTea,
which is a way to build OpenJDK using free GNU tools.

00:30:03.932 --> 00:30:10.344
When you're building using OpenJDK, I think there's still some thing that aren't completely open source.

00:30:10.598 --> 00:30:13.191
If I'm not mistaken.

00:30:14.358 --> 00:30:19.312
With IcedTea, you can also do cross compiles, so i can compile Jamiga-stuff on that.

00:30:19.312 --> 00:30:25.990
Otherwise I have to compile everything on the Amiga, and it actually isn't that fast.

00:30:27.868 --> 00:30:31.768
And that's where I am right now.

00:30:32.246 --> 00:30:42.180
If you want more information, you can follow me on twitter or look at my blog.
If you want info on Amiga, you can go to http://amigaos.se

00:30:43.906 --> 00:30:47.209
That's it. Thank you!
Questions?

00:30:47.712 --> 00:30:54.442
Audience: what was the biggest challenge? Is it this with the threads?

00:30:54.442 --> 00:31:05.157
Currently its cross-compiling OpenJDK, but previously it was...

00:31:05.157 --> 00:31:17.632
... mostly time... to find the time to fix everything.

00:31:17.632 --> 00:31:27.171
Much of the work isn't very advanced, but it's
these sort of bugs that is the hardest part.

00:31:27.769 --> 00:31:42.074
Audience: what is the process model on the new Amiga? Back in the days, 
all memory was shared, and you could peek wherever you wanted.

00:31:43.049 --> 00:31:49.000
It's not possible to do that anymore, if you do that, the Grim Reaper will appear.

00:31:49.254 --> 00:31:57.994
Audience: But wasn't that the case in Os 3.1. You could enable the MMU somehow.

00:31:57.994 --> 00:31:59.585
Eh... er...

00:31:59.850 --> 00:32:10.073
Yes, that's correct.

00:32:10.483 --> 00:32:14.927
Audience: but the model was to send pointers.

00:32:15.768 --> 00:32:19.097
Yes, er, that's still kind of like it is.

00:32:19.097 --> 00:32:24.379
When you allocate memory, you can tell it to be"public" so other processes can reach it.

00:32:24.379 --> 00:32:29.331
But you can also say that it's private, which is the preferred way.

00:32:29.331 --> 00:32:35.575
But when two processes need to talk to each other, the memory needs to be "public".

00:32:35.575 --> 00:32:38.494
Audience: and "public" is globally, shared?

00:32:38.687 --> 00:32:42.061
Yes.

00:32:42.727 --> 00:32:54.527
Audience: Have you found functions not available on Amiga? You mentioned the crypto-secure-random....

00:32:55.118 --> 00:33:01.251
Audience: ...but have you found something where you had to port a third party library.

00:33:01.629 --> 00:33:09.375
no.. no.. well.

00:33:09.375 --> 00:33:15.729
The JVM and GNU Classpath has a few dependencies, but most them are available.

00:33:16.021 --> 00:33:18.893
Or, well, the Posix-threads doesn't exist.

00:33:19.119 --> 00:33:23.929
Or, there is a support for Posix-threads, but that implementation lacks a few things.

00:33:23.929 --> 00:33:27.417
So I made my own Posix-thread implementation which is very Jamiga specific.

00:33:27.417 --> 00:33:33.755
So you can't use anywhere you like, sadly, 
but it works for JAmiga.

00:33:34.749 --> 00:33:41.788
Audience: You mentioned AWT, but why not SWT?

00:33:42.850 --> 00:33:51.573
Er... SWT.... isn't that Swing in the background? Or is that AWT?

00:33:51.951 --> 00:34:07.434
Audience: SWT has its own native libraray, and is nät oart of the java standard.

00:34:07.912 --> 00:34:14.985
Audience: so SWT isn't standard, and that's why you don't mention it?

00:34:15.509 --> 00:34:38.908
Audience: (some discussion on SWT, AWT, etc): SWT is horrible. Don't go there.

00:34:39.397 --> 00:34:42.371
Sounds like I shouldn't bother with SWT... atleast not now.

00:34:42.911 --> 00:34:49.458
Audeince: Do you have any more commiters in the project?

00:34:49.458 --> 00:34:58.228
I had one who helpd with some MorphOS parts, but, no, now its just me.

00:34:58.825 --> 00:35:03.952
And lately, it's not been much from me either.

00:35:04.237 --> 00:35:07.488
Audeince: What about test code. Does Rocale have that?

00:35:07.488 --> 00:35:17.321
Yes... Oracle has some test-sets, JTreg I think its called.
I haven't looked at that much.

00:35:17.321 --> 00:35:23.888
However, GNU Classpath has "Mauve", which is an entire test suite for all Java classes.

00:35:24.197 --> 00:35:36.322
If you look at my blog, I've listed what is tested,
and I think like 80 % is covered.

00:35:37.726 --> 00:35:40.272
But, yes. Test suite exists.

00:35:44.424 --> 00:35:46.352
Thank you!

00:35:48.297 --> 00:35:51.105
A movie by Joel Edberg