0:00:11.792,0:00:15.712
Saturday the 19th September 2015

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

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

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

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

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

0:01:12.604,0:01:16.749
They started creating Java for Amiga.

0:01:16.749,0:01:23.089
and released a version in 2005, and then nothing much happened[br]until around 2009 when I began looking at it.

0:01:25.084,0:01:30.574
At that time they supported parts of Java 1.4.

0:01:32.460,0:01:38.023
If you know something about Java, you'll get something from this,[br]and if you know nothing about Java, I hope you'll also get something out of this.

0:01:39.063,0:01:44.999
So hopefully everyone will be happy at the end, [br]or everyone will be confused by my ramblings.

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

0:01:53.221,0: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.

0:02:01.385,0: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.

0:02:13.586,0: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.

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

0:02:35.854,0:02:41.496
Audience question: can you run old Amiga applications on this new computer?

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

0:02:55.166,0: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?

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

0:03:09.897,0:03:12.613
Audience question: Have they removed the Guru meditation?

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

0:03:23.767,0:03:28.745
So the guru is gone, but problems persist.

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

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

0:03:50.566,0:03:54.862
We'll start with the JVM.

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

0:04:02.328,0:04:18.867
It execute bytecode, and bytecode is the JVM's internal instructions, [br]just like an x86 processor has x86 instructions, and PPC has PPC instructions.

0:04:18.867,0:04:24.367
The JVM translates from bytecode to processor instructions.

0:04:24.367,0:04:33.313
In the most simple case, it's relatively easy. [br]One instructions have its obvious counterpart.

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

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

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

0:04:51.579,0:04:56.989
The JVM also handles memory and that stuff.

0:05:00.174,0:05:04.583
Going right we come to the class library.

0:05:05.594,0:05:10.710
And this is basically the Java SE standard.

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

0:05:16.322,0:05:21.581
And it's basically Oracle that decides how this should look.

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

0:05:31.413,0:05:40.690
This is stuff like handling lists, writing to the console, [br]open files, and, handling XML and various things.

0:05:44.797,0:05:51.132
In order to for instance open a file, we need to somehow get [br]access to the underlying operating system.

0:05:51.689,0:05:55.319
For this we have the native library.

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

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

0:06:11.220,0: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.

0:06:22.690,0:06:27.182
And this is basically the parts we have in a JVM.

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

0:06:35.301,0:06:41.837
The class library and the native library are closely tied together.

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

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

0:07:06.425,0:07:11.264
In the beginning OpenJDK wasn't "Open"

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

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

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

0:07:46.429,0:07:53.453
They implemented everything in the Java standard from scratch.

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

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

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

0:08:16.913,0:08:18.608
A few different JVM options

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

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

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

0:08:39.929,0:08:47.669
Some of the JRockit developers are like working a t Oracle now.

0:08:49.060,0:08:53.910
Microsoft and MacOS had their own JVMs up until 2001.

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

0:09:01.430,0:09:04.571
But then they skipped them, and let people decide themselver

0:09:04.903,0:09:08.584
Then we have onw called "Kaffe".

0:09:08.834,0:09:13.863
Its open source, and it support GNU Classpath

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

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

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

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

0:09:45.198,0:09:50.936
So the bytecode is translated to x86 or PPC code.

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

0:10:00.394,0:10:05.656
Then I can also mention Dalvik which is Android's VM.

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

0:10:15.202,0:10:20.774
But, lets focus on this VM JamVM.

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

0:10:29.898,0:10:34.195
It uses Posix threads, and it supports PowerPC.

0:10:34.218,0:10:38.955
So I thought this was good and interesting.

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

0:10:44.338,0:10:46.440
And that is what I've done.

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

0:10:55.418,0:11:02.157
So when I'm developing, I'm porting JamVM.

0:11:04.071,0:11:10.121
A small summary. [br]The JVM is JamVM

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

0:11:19.154,0:11:21.079
So I've continnued with that.

0:11:21.353,0:11:25.680
Native libraries are .library, and operating system AmigaOS 4.1.

0:11:31.923,0:11:40.492
I can talk a bit about the interface of GNU Classpath.

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

0:11:45.695,0:11:50.018
And there's a number of different native libraries.

0:11:50.018,0:11:53.542
And these libraries corresponds to the Java packages.

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

0:12:02.704,0:12:11.644
A small screen shot over GNU Classpath file structure.

0:12:11.644,0:12:17.729
On the right side we see the Java standard class "java.lang.System".

0:12:17.729,0:12:21.507
This has some connectiosn down to the operating system.

0:12:21.507,0:12:25.287
And those connectiosn can be found in the "java.lang.VMSystm" class.

0:12:25.287,0:12:28.337
And that is a pretty nice connection.

0:12:28.337,0:12:38.854
If we have a Java class, wee know which native class we should look in,[br]to find connections to the OS.

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

0:12:48.201,0:12:53.116
And now we're going to run some Amiga.

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

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

0:13:03.313,0:13:06.957
Here we have a small Java program.

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

0:13:12.668,0:13:16.392
I.e. "Hello World" in Java.

0:13:16.392,0:13:22.494
And we're going to see what happens "under the hood".

0:13:22.494,0:13:24.840
Audience question: is your laptop an Amiga machine?

0:13:24.840,0:13:25.773
No.

0:13:25.773,0:13:28.008
No. Its an Ubuntu.

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

0:13:30.589,0:13:36.469
So this is just pictures.

0:13:36.883,0:13:43.824
We begin here in "Java.lang.System"[br]"System" is a class in the java standard.

0:13:43.824,0:13:47.265
And then we have an object "out" here.

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

0:13:53.760,0:14:01.478
And if you know your Java, you know that PrintStream has a method "printline",[br]which print a line to the stream.

0:14:01.478,0:14:09.455
Then we need to look at what "out" is initialised to.

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

0:14:15.078,0:14:20.096
So we move along to that class.

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

0:14:29.840,0:14:34.419
And here we have a method "makeStandradOutputStream"

0:14:34.419,0:14:40.045
This returns a PrintStream, which wraps around a BufferedOutputStream[br]that wraps around a FileOutputStream...

0:14:40.045,0:14:45.475
If you know your Java, you know about these streams... [br]but we'll ignore that for now.

0:14:45.475,0:14:50.165
The main thing here is the "FileDescriptor.out".

0:14:50.165,0:14:53.772
This is just ordinary Java code.

0:14:53.772,0:14:56.724
But this "FileDescriptor.out" is a bit interesting.

0:14:56.724,0:15:01.601
So we move on that.[br]We end up in a new class: "FileDescriptor"

0:15:01.601,0:15:05.398
And that has an object named "out" up there.

0:15:05.398,0:15:14.973
And.. that is a FileDescriptor object, which has an [br]parameter FileChannelImpl.out, again.

0:15:14.973,0:15:18.832
So we move on to the class "FileChannelImpl".

0:15:18.832,0:15:25.697
And there we find the object "out", somewhere... [br]There!

0:15:26.977,0:15:31.718
And if we look here; here we load our library "javanio".

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

0:15:43.858,0:15:46.140
We continue with "out".

0:15:47.263,0:15:53.514
Down here we see "out=ch". [br]And "ch" we previously set to a FileChannelImpl.

0:15:53.514,0:15:59.359
Which is wrapped around a "VMFileChannelImpl.getStandardOut()".

0:15:59.359,0:16:05.658
So we move along to the "VMFileChannelImpl" class

0:16:05.658,0:16:10.390
And then we see the method "getStandardOut()"

0:16:10.390,0:16:16.584
And that methd is here "getStandardOut",[br]which return a new VMFileChannel

0:16:16.584,0:16:25.851
And calls a method "stdout_fd",[br]which is here, and it has no method body...

0:16:25.851,0:16:31.839
However, it has a intereseting word here: "native"

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

0:16:37.551,0:16:42.183
And now we will go from Java to C.

0:16:42.183,0:16:47.593
So this is C code.

0:16:47.593,0:16:53.712
And this is the function that is executed when we call this native method.

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

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

0:17:08.424,0:17:15.733
So the pointer to the console is returned into the Java code,[br]and going all the way back...

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

0:17:33.214,0:17:38.493
So this is some explanation to why Java is a bit slow to start up.

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

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

0:17:58.860,0:18:05.040
This call.... er... eh

0:18:05.647,0:18:13.539
This call, from Java code to C code,[br]looks a bit magic.

0:18:13.539,0:18:19.249
And it is a bit magic, [br]but not much.

0:18:19.277,0:18:29.814
How does the JVM know which native method it should find?

0:18:30.487,0:18:39.295
From out antive libaray we can export different functions.

0:18:39.295,0:18:51.666
In the Java standard, it is defined that all native [br]functions will have a standard name,

0:18:52.231,0:19:00.369
with a prefix, followed by the java package, method name and arguments,[br]so the VM can find the method.

0:19:02.580,0:19:13.564
And with these small header definitions in the C code,[br]the compile knows that these functions should be exported

0:19:15.142,0:19:18.751
But this is not how it works on the Amiga.

0:19:18.751,0:19:26.700
In the Amigas native libraries we only export on function "getLibraryContent"

0:19:26.700,0:19:33.977
And that returns a strcture where the JVM can do the lookup.

0:19:34.555,0:19:44.149
So that is one difference in Amiga.

0:19:46.132,0:19:49.438
Then ,some more code.[br]A different example.

0:19:49.803,0:19:54.498
We're going to look at the class VMSecureRandom.java

0:19:55.784,0:20:00.210
The VM prefix tells us that there might be antive calls in here.

0:20:00.833,0:20:11.712
And this class generates a random seed,[br]which is used by f.i. cryptography.

0:20:13.578,0:20:21.775
And one of my users that tested Jamiga,[br]found a small crypto library

0:20:21.775,0:20:22.296
However, when executing it, the entire machine locked up.

0:20:28.256,0:20:35.694
And this is the VMSecureRandom class.[br]The detalis aren't important.

0:20:35.694,0:20:40.651
But here we have the method "generateSeed",[br]that generates our seed.

0:20:40.651,0:20:44.309
It does this by starting 8 threads that spins,[br]and increments a counter,

0:20:44.309,0:20:50.282
and then randomly they will end,[br]and then we'll end up with a random value.

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

0:21:01.106,0:21:06.952
however, I managed to shorten this method to this.

0:21:06.952,0:21:12.290
Here we instead open a file from the Amiga device "Random:"

0:21:12.290,0:21:20.273
Which generate random numbers.

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

0:21:25.532,0:21:38.597
As an example we have here a variant from a Unix flavor,[br]wirh a native call to his C code.

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

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

0:21:55.335,0:22:01.690
And this just throws an exception, that this [br]method isn't supported on Win32.

0:22:03.361,0:22:08.842
Oh no! The Guru meditation!

0:22:09.221,0:22:12.514
Not at all planned.[br]Oh no. How annoying.

0:22:12.514,0:22:20.049
Another problem i had,[br]was how these threads are handled.

0:22:20.049,0:22:30.126
I experienced some problem when adding network support

0:22:31.563,0:22:37.650
I started a Java program[br]which opens a socket

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

0:22:43.855,0:22:53.631
And I thought it might be nice to put in its own thread,[br]so the main thread can do other stuff.

0:22:54.373,0:23:00.214
We create a socket,[br]and a new thread.

0:23:00.978,0:23:06.002
And then I try to read from the socket here.

0:23:07.068,0:23:13.879
But then I got this error:[br]apparently, the socket, isn't a socket!

0:23:14.744,0:23:16.433
Much strange.

0:23:21.238,0:23:25.079
But if you read the Amiga docs...

0:23:25.079,0:23:33.461
You'll find that this socket [br]only exists within this process.

0:23:33.461,0:23:42.276
There are ways to circumvent this,[br]they are bit troublesome.

0:23:42.565,0:23:51.999
So instead I here created a [br]new socket process.

0:23:51.999,0:24:01.042
So instead of sending the socket ID, I instead send [br]a reference to the process.

0:24:01.296,0:24:17.365
We'll continue with these threads.

0:24:18.094,0:24:24.607
I mentioned that JamVM uses Posix-thread,[br]where AmigaOS has processes.

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

0:24:38.501,0:24:46.241
The AmigaOS processes has a few connections to DOS library and such.

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

0:24:52.453,0:24:55.298
It's sort of all gone in Amiga OS 4.

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

0:24:58.713,0:25:02.855
Ah, yes, yes, that's still there.

0:25:02.855,0:25:15.851
An AmigaOS process is a "task", which is more lightweight.[br]But the Amiga process has connections to DOS.

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

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

0:25:45.273,0:25:49.502
We're going to see how this looks when its running on the Amiga

0:25:50.263,0:26:09.232
Each new JVm instance, has beside the main process,[br]also have three JamVM specific Amiga processes.

0:26:09.232,0:26:12.686
We have a Reference handler, Finalizer, and Signal handler.

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

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

0:26:30.265,0:26:34.288
And the Signal handler handles signals sent to the program.

0:26:35.310,0:26:38.863
So it kind of looks like this.

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

0:26:48.877,0:26:53.020
Ctrl-C is handled by the signal handler.

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

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

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

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

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

0:27:35.928,0:27:38.458
But not in the Amiga case.

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

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

0:27:51.254,0:27:58.941
Receiving that signal, the main process ends the three subprocesses,[br]frees memory,closes libraries, and then exists.

0:28:01.627,0:28:04.942
And with that, I'm almost done.

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

0:28:15.709,0:28:19.833
There's also a few automatic updates available.

0:28:20.331,0:28:29.648
Somewhat completet support for Java 1.5,[br]however no graphics or AWT.

0:28:33.851,0:28:40.634
I also have a small Twitter client,[br]which uses Twitter4j.jar

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

0:28:48.737,0:28:52.352
which creates a small tweet.

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

0:28:57.476,0:29:02.478
The plan ahead is to support OpenJDK

0:29:02.892,0:29:11.178
And this a small test i ran, which shows that I'm missing java.libraray,[br]which I must implement.

0:29:12.113,0:29:17.194
JamVM supports OpenJDK, out of the box.

0:29:18.636,0:29:23.915
I'll also try to fix graphics stuff.

0:29:27.339,0:29:32.124
Just to mention a few ways to build OpenJDK.

0:29:32.475,0:29:38.618
You can either build it like Oracle wants you to.

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

0:29:50.574,0:30:03.665
Alternatively, you can build it using IcedTea,[br]which is a way to build OpenJDK using free GNU tools.

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

0:30:10.598,0:30:13.191
If I'm not mistaken.

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

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

0:30:27.868,0:30:31.768
And that's where I am right now.

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

0:30:43.906,0:30:47.209
That's it. Thank you![br]Questions?

0:30:47.712,0:30:54.442
Audience: what was the biggest challenge? Is it this with the threads?

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

0:31:05.157,0:31:17.632
... mostly time... to find the time to fix everything.

0:31:17.632,0:31:27.171
Much of the work isn't very advanced, but it's[br]these sort of bugs that is the hardest part.

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

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

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

0:31:57.994,0:31:59.585
Eh... er...

0:31:59.850,0:32:10.073
Yes, that's correct.

0:32:10.483,0:32:14.927
Audience: but the model was to send pointers.

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

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

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

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

0:32:35.575,0:32:38.494
Audience: and "public" is globally, shared?

0:32:38.687,0:32:42.061
Yes.

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

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

0:33:01.629,0:33:09.375
no.. no.. well.

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

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

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

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

0:33:27.417,0:33:33.755
So you can't use anywhere you like, sadly, [br]but it works for JAmiga.

0:33:34.749,0:33:41.788
Audience: You mentioned AWT, but why not SWT?

0:33:42.850,0:33:51.573
Er... SWT.... isn't that Swing in the background? Or is that AWT?

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

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

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

0:34:39.397,0:34:42.371
Sounds like I shouldn't bother with SWT... atleast not now.

0:34:42.911,0:34:49.458
Audeince: Do you have any more commiters in the project?

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

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

0:35:04.237,0:35:07.488
Audeince: What about test code. Does Rocale have that?

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

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

0:35:24.197,0:35:36.322
If you look at my blog, I've listed what is tested,[br]and I think like 80 % is covered.

0:35:37.726,0:35:40.272
But, yes. Test suite exists.

0:35:44.424,0:35:46.352
Thank you!

0:35:48.297,0:35:51.105
A movie by Joel Edberg