Jun 2004
1 / 83
Jun 2004
Feb 2019
Adrian_Kosowski
Jun '04

The main class of the program must be called Main.

A sample solution using standard JDK classes:

public class Main
{
  public static void main (String[] args) throws java.lang.Exception
  {
     java.io.BufferedReader r = new java.io.BufferedReader (new java.io.InputStreamReader (System.in));
     String s;
     while (!(s=r.readLine()).startsWith("42")) System.out.println(s);
  }
}

  • created

    Jun '04

  • last reply

    Feb '19
  • 82

    replies

  • 8.0k

    views

  • 46

    users

  • 4

    likes

  • 8

    links

Frequent Posters

Popular Links

70MICEMAZE Runtime Error (NZEC discuss.spoj.com
47http://www.swageroo.com/wordpress/solving-spoj-problems-life-the-universe-and-everyth...
21http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html
14PrintWriter (Java Platform SE 7 ) docs.oracle.com
5Ideone.com - x814eI - Online Java Compiler & Debugging Tool ideone.com

There are 82 replies with an estimated read time of 14 minutes.

1 month later
Daniel_Bonniot1
Jul '04

Is it really possible to use external libraries like com.braju.beta.format in submissions? How would they be found?

Adrian_Kosowski
Jul '04

I am afraid the answer to your question is no; allowing this would pose a great security hazard. This particular library, com.braju.beta.format, has been manually added to the classpath smile, and sometimes proves useful, particularly when reading input data. If you know of a library that might help improve the quality of JAVA support in SPOJ, please provide us with the appropriate package or link.

Daniel_Bonniot1
Jul '04

OK, I understand how it's working at the moment.

I'm not sure why allowing any library would pose a security threat, though. Anything that a library does, the main program could also do it, with the same result. (I would think that the right way to ensure security would be to run programs inside a chroot fail, at least if your server is a Linux/Unix system. For Java, you could additionally set up a security manager).

Actually, I was wondering if you could consider allowing submissions in bytecode format (inside a jar, possibly with a maximum size) as well as in Java source. Benefits:

  1. Allow submissions to use any library, provided the submitter packages that library inside his jar.
  2. Instantly allow submissions to be written in one of the hundreds of languages that compile to java bytecode (see flp.cs.tu-berlin.de/~tolk/vmlanguages.html21). I think that would make many people interested in non-mainstream languages happy.
  3. Save some compilation time on the server wink
Adrian_Kosowski
Jul '04

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.

Daniel_Bonniot1
Jul '04

I'm glad you like the idea.

In what case do you show the source code? I guess that's not critical, so it could be disabled in this case, at least in the begining. Especially as there would also need to be a convention about where the source code (which might not be Java) is inside the jar. So in a first step, it should be enough to accept jar files, do nothing in the compilation phase, and then start then with 'java -jar ...'

Regarding the 50000 byte limit, I guess it should be OK, especially as one can run an optimizer on the jar to strip off dead code before submission. I agree some general purpose libraries could still be installed on the server if there is demand for them.

Adrian_Kosowski
Jul '04

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)?

DanielBonniot
Jul '04

Yes, that would be fine, and I see it would make your job easier. Although honoring the Main-Class attribute in the manifest if it exists would be practical for some users (some languages always compile code that is inside packages, so cannot directly generate code for a class Main in the default package). The decision could be made based on the exit code of 

jar tf submission.jar | grep META-INF/MANIFEST.MF

.

Adrian_Kosowski
Jul '04

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

NB. If you know of anyone (e.g. yourself wink ) 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.

system
Jul '04

Great, thanks!

Hey, I see you have been doing some private investigation wink

Yes, it would be cool to have Nice added. I will try problems once in a while, and I will point to your project on our mailing list once it is. It's motivating to have tasks like this when you are learning a new language.

Technically, if the judge is like a server a Debian machine, you can

apt-get install nice
Daniel_Bonniot1
Jul '04

Oops, submitted by accident.

If you want to accept a single nice source file as entry, you can compile it like this: put it file with '.nice' extension in a 'main' subdirectory, then call

nicec --classpath <external libraries> -a main.jar main

and then run with

java -classpath main.jar:<external libraries> main.dispatch

The idea is the same external libraries that are available for Java programs could also be used in Nice programs.

Adrian_Kosowski
Jul '04

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?

Daniel_Bonniot1
Jul '04

You mean use the classes from JDK 1.4 with the VM of 1.3? Why would you want to do that?
In any case, it seems it wouldn't work (here with 1.4 and 1.5beta):

java -Xbootclasspath:/usr/local/opt/jdk1.5.0/jre/lib/rt.jar
Error occurred during initialization of VM
java.lang.NoSuchMethodError: java.lang.Thread.start()V
noix
Jul '04

"Bytecode" language is added (simply send a .jar) smile We'll also add Nice, probably today..

Daniel_Bonniot1
Jul '04

Great, thanks a lot!

How are jars handled at the moment? Started with Main, the main-class in the manifest, both?

Adrian_Kosowski
Jul '04

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?

system
Jul '04

Not directly. Is that a problem?

I know the jar will be above the default limit, but that should not matter when submitting Nice source, right? Also, it's possible to use a tool to cut down on dead code. I tried proguard, and a simple Nice program gives a 17K jar file.

Adrian_Kosowski
Jul '04

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.

Daniel_Bonniot
Jul '04

Cool! I just solved TEST in 0.89s. Must have found a more clever algorithm wink

Did you also use a tool to cut down the size, or did you internally bypass the size limit to run a nice program as JAR?

Adrian_Kosowski
Jul '04

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

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.