Solution to TEST in Java

You misunderstood me. I meant that allowing a program to download a library from the Internet at compile time or at runtime would pose a security threat. Chroot or no chroot, it could run loose and e.g. spam the wide world.

Sounds like a good idea. The only problem is the binary format of the submission; a little work must be done to adapt advanced features like viewing source by the user, etc.

You also have to take two things into account: 1) java has slow i/o as a language and as a result about 1/3 of the problems cannot be solved in it; 2) the submission size is limited by the problemsetter (as a rule to 50000 bytes); this would probably also have to apply to jar files. I think larger libraries should be preinstalled in the online judge on request.

Thank you for your helpful suggestions.

It is only shown when a user, having logged in, clicks on a submission ID. It ought to be enough to set the mime type correctly as application/zip or something like that, so that the browser would try to save the file rathen than open it. As I said, this is not a problem.

The scripts that we use to compile java simply generate an archive containing all the class files. At runtime this archive is added to the classpath and Main is set as the startup class. Perhaps the bytecode input could just consist of such a zip/jar file (possibly even without a manifest)?

I think we will start off with a simple jar, and work on the manifests as we go along .

NB. If you know of anyone (e.g. yourself ) who would wish for the nice compiler to be included as a separate language, please tell us. We can add a language if it seems likely that somebody is going to solve problems in it.

Thanks. When Noix gets back from holiday (perhaps today?) we will add the two new languages. Once we are about it, I think we will try to modify the system in such a way as to keep one jdk installation for "java", "nice" and "bytecode-java" (to improve maintainability).

BTW. I wonder whether jre1.3.1 would work with a newer class library?

At present - with Main. We will add the manifest option when configuring Nice.

Is it possible to disable the inclusion of standard (library) classes in the jar file generated by the Nice compiler?

OK, jar files with/without manifests are now supported. Nice compiled to Bytecode works for TEST in 0.99s. The Nice compiler will be made available tomorrow.

I just changed the submission size limit for the problem TEST for a moment .

But thanks for mentioning proguard; I hadn't realised that there existed an open source java obfuscator. These can get quite handy sometimes, especially if privacy (not necessarily secrecy) of source code is required.

I am afraid the post you are referring to was a little out of date. Indeed, until about a month ago we were using Blackdown JAVA 1.3, and the com.braju.beta.format.Format was available (it worked about twice as slowly as normal IO).

This class was not included in the new Java installation (Sun JAVA 1.5 beta2) for the simple reason, that the newly added standard classes java.util.Scanner and Formatter (as well as the printf method for some other classes) seemed to make it redundant.

Please note that since Sun's JDK 1.5 beta2 differs significantly from 1.5 beta1, and is much closer to the current ReleaseCandidate, you should only use the official documentation of these classes, and not other sources found in the Internet (since they are mostly out of date).

The following is an example of code that will work with the online judge:

import java.util.Scanner;
class Main
{
   public static void main (String [] args)
   {
      /*
         // equivalent C code fragment
         int i;
         float f;
         char s [50];
         printf ("Enter three values -- integer float string: ");
         scanf ("%d %f %s", &i, &f, s);
         printf ("%d %f %s\n", i, f, s);
      */
      System.out.printf ("Enter three values -- " +
                        "integer float string: ");
      Scanner sc = new Scanner (System.in);
      int i = sc.nextInt ();
      float f = sc.nextFloat ();
      String s = sc.nextLine ();
      System.out.printf ("%d %f %s\n", i, f, s);
   }
}

But if you find that these classes do not meet your requirements, please let us know and we will add com.braju.beta.format to the classpath; this is no problem whatsoever.