Woz-
I have not tested GCJ myself yet but have noticed on the site news this message:
Its a bit dated of a post so I am figuring this issue has been resolved already. I was just curious if you knew of any other issues still outstanding.
I guess the best way to find out is to just port a few apps over and see what happens.
Bob,
Ahh, I thought you ment there was an issue between MinGW and GCJ! :
Yes, there are LOTS of problems with GCJ when refering to Java as the GNU libraries (libgcj) are far from complete.
How ever libgcj should only be neccessary if you are compiling to machine code or using gij (GNU Interpreter for Java) to run Java classes via gcj.
Even then it is apparently possible (IOW I haven’t tried it my self) to run software such as http://www.eclipse.org/ in gij.
So this was what I was hoping to find out, exactly how much of the libraries are complete or needed by us to get “things” working.
Here are the two main articles that sparked me into having another go with GCJ (tried ages ago and got no where).
Running Eclipse with GIJ:http://www.klomp.org/mark/gij_eclipse/index.html
and
Compiling Java with GCJ by Per Brothner:http://www.linuxjournal.com/article.php?sid=4860
Woz.
P.S.
I have now added instructions on how to get GCJ running under the NT series (NT3.51, NT4, 2000, XP etc).
http://realmdesigns.russki.net/?command=tutor&t=0
Just to keep people informed about GCJ V3.2,
I have got the odd Java Application to compile to a .exe, although these are Applications that are devoid of a UI and that don’t rely on the AWT or SWING as these don’t exist in GCJ V3.2 (the odd stub files found lying around in the MinGW directory are not connected to anything higher up).
After further looking around it looks like the only GUI that will work with GCJ V3.2 is SWT (http://www.eclipse.org).
I thought about various others that might work, such as JavaGL but came to the conclusion that these all rely on the AWT - which doesn’t exist yet.
So what is required is a DLL interface to the outside world via JNI.
An article by Kirk Vogen about get SWT to work with GCJ can be found here: http://www-106.ibm.com/developerworks/library/j-nativegui/. Although concerning GCJ 3.1 and Linux.
A Post in the GCC mailing list by Ranjit Mathew discusses how to get SWT and GCJ V3.2 to work with Win32 : http://gcc.gnu.org/ml/java/2002-12/msg00105.html
GCJ V3.3 will hopefully change this, although from what I’ve read it looks like lots of features will end up in V3.4 but I could not find a release date for this.
GCJ V3.3 is due for March 1st 2003 :D, although it will take time before a version in MinGW is available.
Woz.
Couldn’t care less about AWT So long as it can JNI to LWJGL that’s just great.
Cas
Squeeto has kindly pointed out that Mohan Embar has managed to cobble together a preview of GCJ V3.3.
Now its even simpler to get GCJ V3.3 running as MinGW has already been included and its just a case of unzipping the file and adding the “bin” directory to your path.
However it is a big download (and remember it is JUST a preview - some of the patches may not be allowed into the final build) at some 25Meg.
It’s also appears to be on a slow connection, took me 3 hours 
on my modem.
The main goal seems to be to get SWT working better, as well as some bits like processes.
I managed to get bother processes (missing in V3.2) and SWT running with this preview version.
the Preview GCJ V3.3 can be found at:
http://www.thisiscool.com/gcc33_mingw.htm
But remember that the FULL version of GCC V3.3 is due in a couple of weeks anyway (fingers crossed), but I thought I’d let you all know.
Woz.
P.S.
Take it easy.
I might get Brian to compile Alien Flux with it (seeing as he’s got a willy-waving cable modem and can spare a 25Mb download…). I’ve just bought Jet at a grand cost of £500 and I’ll be incredibly miffed of course if gcj is faster :o
Cas
[quote]I might get Brian to compile Alien Flux with it
[/quote]
lot’s of these:
warning: unreachable bytecode from 277 to before 280
where 277 & 280 obviously vary.
and this one too:
xap/features/EntityFeature.java: In class `xap.features.EntityFeature':
xap/features/EntityFeature.java: In method `xap.features.EntityFeature.tickAllEntities()':
xap/features/EntityFeature.java:385: error: class 'xap.features.EntityFeature$EntityInstance' has no method named 'inCollisionWith' matching signature '(Lxap/Entity;)V'
xap/features/EntityFeature.java:386: error: class 'xap.features.EntityFeature$EntityInstance' has no method named 'inCollisionWith' matching signature '(Lxap/Entity;)V'
xap/features/EntityFeature.java:386: confused by earlier errors, bailing out
What is Alien Flux?
At the moment I don’t think GCJ would be faster than Jet as GCJ is still in it’s early stages.
But then you have the ability to turn off bounds checking with GCJ, which is the bit making my fingers itch!
Of course I don’t actually have Jet to make a comparision, which sounds like a job for you Cas 
Neither would it meet you magic 5 Meg file size at the moment, as even simple applications are compiling to around 4 meg. Although interestingly the files are initially 1/3 smaller, then mysteriously bump up a meg or so.
Those error messages look quite confusing, I haven’t encountered them at all (or at least don’t remember).
If this is a large project try starting with a small section and get that running - then enlarge.
It might be just that it is not finding the correct files, although GCJ does have some quirks in its language parser.
things like this:
import java.awt.image.*;
did not work for me, I had to make my libraries explicit
import java.awt.image.MemoryImageSource;
import java.awt.blahblahblah;
(Note: not that the awt exists in GCJ V3.2, I just used it as an example!)
Woz.
Jet seems to be removing bounds checks where it’s safe to do so by using loop versioning and other tricks. At any rate, I’ve gotten the entire Alien Flux distribution down to under 5Mb - an exe and 2 dlls with Wise to install it - what’s amazing about this is that the bytecode distribution is only a megabyte smaller!
Cas
Hi all,
just thought I’d inform you all that a slightly newer version of the GCC has been release.
I say slightly because its Version 3.2.3 which is a bug fix for V3.2.2.
try: http://gcc.gnu.org/gcc-3.2/changes.html#3.2.3
It does contain a couple of bug fixes for GCJ, but I don’t think it will effect any one here (anyone running irix???!).
Bug fixes:
I have no idea why Version 3.3 has not been released yet, althought the preview is still available (can be found in a post above) and works a just fine.
Woz.
P.S.
As a side note I noticed Out-of-the-Box 2.0 has been released, which may/may not interested people:
http://www.ejbsolutions.com/new-projects.html
Hi,
I’ve just started playing with GCJ, and running up to the import problem, does anyone know of a tool to change the imports automaticly?
In a unix enviroment I’d use sed.
On Win32 I don’t know but I’d start looking at the filter ability of Ant’s copy task and see if I can get it to search/replace what I want.
OK, supposed to be revising for my exams, so obviously been playing with gcj all day!
I’ve now got a compiled helloworld down to just under 1/2 meg by stripping out all symbols and running through upx. This is supposedly the full runtime as well, so looking good
nio is partly there, but not direct buffers yet, so still no lwjgl support. Shouldnt be long though as the stubs are there, just needs an implementation.
I’m all set up to compile the runtime as well now, so I’m going to try stripping out all the stuff I dont need from the library and see if I can get the file size down even more…
[quote]In a unix enviroment I’d use sed.
[/quote]
Woo, writing sed files, the fun…
Anyway worked it out, compile it with javac
GCC 3.3 is released,
containing quite a few changes to GCJ, although not really enough to be useful to most of you. So we’ll have to wait for version 3.4 - which was expected anyway.
New GCJ features:
* The java.sql and javax.sql packages now implement the JDBC 3.0 (JDK 1.4) API.
* The JDK 1.4 assert facility has been implemented.
* The bytecode interpreter is now direct threaded and thus faster.
But contains plenty of bug fixes, there is to many to list but can be found here http://gcc.gnu.org/gcc-3.3/changes.html.
The www.mingw.org version is not yet ready (judging from source forge), but should be soon-ish…
Just to clear up what Jacko is saying:
Here is the most exciting “hello world” program, in java:
public class hello
{
public static void main(String[] args)
{
System.out.println("Hello World");
}
}
Compiling this file using GCJ to produce an .exe file with:
gcj --main=hello -o hello hello.java
Produces a file that is 2,606,061 bytes in size or 2.6Meg !
To remove symbols from the .exe file, compile instead with:
gcj --main=hello -o hello hello.java -Wl,--strip-all
Be careful with the syntax that is an L in the -Wl, it’s also case sensative.
This will produce a file size of 1,816,064 bytes or 1.8 meg.
Using a well known .exe file compressor UPX (Ultimate Packer for eXecutables) by Markus Franz Xaver Johannes Oberhumer (that is just one person) and László Molnár.
This can be located on the UPX web site http://upx.sourceforge.net/.
Using the recommanded switches for best compression :
upx --best --crp-ms=999999 --nrv2d -o hellod.exe hello.exe
Produces a file size of 495,104 bytes or ~483K.
A great improvement on the 2.6 Meg file initially created.
Woz.
P.S.
Jacko get back to the revision! You’ll only regret it if you mess up your exams!
Best of luck with them too!
3.3 is really better as far I tested it (more ocmplete)
but it miss Direct Buffer which screw LWJGL
JNI works
I compiled a LWJGL expample, run it, the window opened but got a message : direct buffer non implemented :(.
elias said it’s for next gcj release
for now it’s going better every release,
good to test often
just to let people know whats going on with gcj…
On www.thisiscool.com there isa development version of gcj 3.4 with … support for direct byte buffers!!
gotta go to a lecture now, but I’ll try this later to see how well it works.
Heh, HelloWorld is now 4.6MB. :o
Other than some really trivial things, I couldn’t get anything to compile and run correctly. Some test programs required some hacks to get it to compile.
For example for doing a quick and dirty new Date().toString(), I finally had to add 2 static references to gnu.java.locale.Calendar.class and gnu.java.locale.LocaleInformation.class in my source, which is a bit weird ???. The little test program BTW is a simple socket that returns the time, but the GCJ version compiles and runs (after inserting the extra lines of dummy code), but behaves differently (I couldn’t test the response from the socket using a browser where I can with the java version).
If I can’t even get these miserable 50 lines of code running, I won’t even bother with compiling a LWJGL program.
Using GCJ is certainly no walk in the field :-[.
I’m not giving up just yet, but so far no result at all.
Thats pretty good figuring a simple HelloWorld in regular java is over 30MB is size.
Now some of you are thinking that I must be crazy BUT you may be forgetting that a GCJ compiled program includes a Java runtime. So, add the size of your JRE with any java app you write to figure the size in comparison.
There is a DLL you can link your GCJ programs to for Windows that takes out the java runtime fat (Google for libgcj.dll). Thats nice if you are planning on having multiple GCJ apps on the same system.
Also, check out UPX (upx.sf.net). Use it to deflate GCJ apps.
upx --best HelloWorld.exe
Yes, this is a known issue. But its the only oddity I have ever seen. What other problems are you having?
Post your code. I curious to whats going wrong.
Here’s my test:
import java.io.IOException;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.Date;
/**
* TServer.java
*/
public class TServer {
private static final Class class1 = gnu.java.locale.Calendar.class;
private static final Class class2 = gnu.java.locale.LocaleInformation.class;
int port;
public TServer(int port) {
this.port = port;
}
public void run() {
boolean waiting = true;
ServerSocket serverSocket = null;
try {
serverSocket = new ServerSocket(port);
} catch (IOException e) {
System.err.println("Could not listen on port: " + port);
System.exit(1);
}
while (waiting) {
Socket clientSocket = null;
System.out.println("Waiting for request");
try {
clientSocket = serverSocket.accept();
} catch (IOException e) {
System.err.println("Accept failed.");
}
PrintWriter out = null;
try {
out = new PrintWriter(clientSocket.getOutputStream(), true);
} catch (IOException e) {
System.err.println("Error getting PrintWriter:" + e);
}
out.println(new Date().toString());
out.close();
try {
clientSocket.close();
} catch (IOException e) {
}
}
try {
serverSocket.close();
} catch (IOException e) {
}
}
public static void main(String[] args) throws IOException {
if (args.length != 1) {
System.out.println("Usage: TServer [port]");
System.exit(1);
}
TServer t = new TServer(Integer.parseInt(args[0]));
t.run();
}
}