JAVA-Difficulties We Face

[veron]

Let's see what type of difficulties we face in our ACM problems to solve with JAVA.Is anyone face this sort of things or not.If you have,then give any opinion for this.please,write your own thought and experience.

Here we want to know what is the common drawbacks of JAVA in ACM Problems.JUST FEEL....
Judge sys of JAVA in ACM,are you think it's OK?Also write on this topic.

PLS don't give any stupid website address,just write your real situation in JAVA.

[xbeanx]

For the most part, I find there are limitations, but these are easily overcome.

Not being able to use BufferedReader is a pain, but one can easily use the readLine() method which is popular on this site.

Not being able to use BigNumbers is also a pain, but since no other language includes libraries or functions for this we are at no greater disadvantage than others.

Lack of formatted input finction is also a pain, but again, very easily overcome. It just takes a couple of extra lines.

Formatted output is also a disappointment. For example. to output PI to 2 decimals, you can just do fprintf("%.2f", pi) in C. In JAVA you can do this with NumberFormat, but it is not supported by the OJ. So you have to write your own method to trim the number. Again, only a few extra lines.

The Collections class is also not supported in JAVA, so if you want to sort an array you must write the sort() method yourself. This is included in C/C++ so this, I believe, is a disadvantage of JAVA at ACM.

For the most part, I haven't hit a limitation yet that has prohibited me solving a problem, with the exception of one. However, after totally rewriting my program to use global variables (instead of locals, which slow recursion a lot in JAVA) it got accepted... Albeit just barely (like 9.89 seconds).


Just so you know, most of the things NOT supported by the online judge can be added to your program by simply copying the code from the JAVA library. BigNumbers is an example of this, as are most methods from the Collections class.

[ggll]

My expericence is that the output speed is the single hugest disadvantage. Most other difficulties can be overcome, easily or not quite easily.

There have been 10+ problems so far that I couldn't solve in Java because of the output speed. In most cases, the results are ready in less than 2 seconds, yet TLE I got.

I was using System.out for output. Anyone knows a faster way?

[Larry]

Indeed, the only limitation/drawback of Java in a real ACM tournament is that sometimes outputting double is a pain..

But otherwise, if you're good enough in it, then it's the same as others..

[Arnold]

Yah I am also realize this similar problem.But overall it's nice language for ACM.

Speed also another typical drawback for solving acm.But I think it's not great cause for java to solve acm.I like it.

[Maniac]

Hello all,

I have tried to use Java for all problems and these are the things that annoy me personally:

- why let us be able to read one character from stdin (System.in.read()) but not a whole line with useful and completely normal tools like a BufferedReader? You tell me, cause I don't understand...

- exceptions always give a WA instead of RTE. I also compete in ACM regional contests (not the ones online) and they all use a judge system where exceptions give RTE's. So is this really impossible to establish?? Right now I always have to check first wether a WA really means WA or RTE, with a try{} catch {} statement. And when I find out that it's an exception that's occuring, I have find out myself what kind of exception this might be (also possible with more try-catch-statements). This costs time and a lot of submisions! Really...

- sometimes when my code gets a bit complicated the judge compiler gives me Internal Compile errors (gcj: Internal compiler error: program jc1 got fatal signal 11). After a LOT of time and effort, I'm now convinced that usually this happens when I use too many dereferences (I mean dots). For example, a statement like

Code: Select all

graph.node[i].edge[graph.node[i].neighbours].end = 4;

could give this internal compile error while

Code: Select all

Node n = graph.node[i];
n.edge[n.neighbours].end = 4;

does not. But you have to find out yourself where the judge compiler gets confused, without clues. Very annoying!

- why use JDK 1.1? Come on, if C++ users can have STL then let us use SDK 1.4. Very basic datastructures like a LinkedList, ArrayList, TreeMap and very basic tools for sorting and formatting of numberes we all have to implement ourselves or do without. What's wrong with a little up-to-date SDK? Now I can't even use a StringBuffer normally cause there's no deleteCharAt() method.

- and I always have trouble with problems where doubles have to be rounded. Also the DecimalFormat class is unavailable, so I have written my own round function. The problem is that my round-fucntion works perfectly, but the C printf("%.3lf") method does not! I've tested this very thoroughly and the printf method is inconsistent in rounding. For example, 19.005 could be rounded up to 19.01 while 20.005 could be rounded to 20.00 (and these are exactly the cases where my round function and printf could disagree). There are multiple problems where converting my code to C++ gave AC where as my Java program gave WA.

- as for time limits, most problems are OK and java programs get AC within time as well. But there are some problems (for example Erdos Numbers, Pascal Sorting Program...) where the input or output is huge and it's nearly or totally impossible to even read and StringTokenize the input before starting to work on the solution without getting a TLE. A little attention to the slow reading and writing of data of Java couldn't do any harm in my opinion...

Concluding, I regret to see that C++ users have all the advantages and Java users all the disadvantages while it doesn't have to be that way. Updating to SDK1.4 would be a great improvement.

Erik

[Arnold]

Yeah,may be you are right but I think there are some sophisticated problem which we face in our contest time.

Overall Java is so good for solving acm.

[chunyi81]

Hello all,

I have tried to use Java for all problems and these are the things that annoy me personally:

- why let us be able to read one character from stdin (System.in.read()) but not a whole line with useful and completely normal tools like a BufferedReader? You tell me, cause I don't understand...

Yup, I agree. In fact, this is much faster. Using a BufferedReader, u can do sth like this:

BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));

Something that is done in abt 20 lines of code in the sample java program for problem 100 can be done in 1 line of code.

[Spike]

Yeah, well I got screwed by the actual ACM regional competition judge.

I submitted a problem in java and I kept getting "Incomplete Output." Turns out my problem was crashing out early because I didn't make my array large enough. So we coded it out in C++ and quickly found the error.

So yeah, it's not just the UVA Judge that sucks. Always make sure to wrap your code so that it times out if there's an error or something. Then you might actually figure out that there's an error.

[technobug]

As it was mentioned before, the lack of some usefull classes really sucks.

Using a jdk1.1 compatible version REALLY sucks.
So when I have to use some real data structures i use C++ + STL, and for everything else I am using Java.

When I need to do some nice graph search algorithm it breaks my heart not to use a simple TreeSet and some AI, but to code it all from scratch...

My group competed for the lsat time at last years South America and we were glad to see that we got 8th place from Brazil just using Java. When you compare it against C++ teams I bet the ratio between places and program language used by teams would show us some nice info about java for this contest....

So, if they would set up UVA as ACM did with us here in Brazil for the South America contest we would see a few more Java programmers on some ranklists.

Guilherme

[mbakht]

Can any of you please enlighten me regarding the Java environment that will be available in WF 2004(Prague) ? Will we be able to use features that are standard in Java but not supported by the valladolid OJ - such as BigInteger?

[Julien Cornebise]

Yeah, well I got screwed by the actual ACM regional competition judge.
(...)
So yeah, it's not just the UVA Judge that sucks. Always make sure to wrap your code so that it times out if there's an error or something.

Thank you for this info that I'd been looking for a while : Java in regionals' can be a pain too... D'you know wether BigInteger were supported ?

A note about BigInteger support in ACM contest, wich can explain the restrictions : if you look closely at JDK 1.4 BigInteger class, you'll see that it almost prepares the coffee ! I mean : primality testing (with several different algorithms), probably prime number generation, basis conversion, bitwise operations, fast exponentiation, modulus arithmetic, etc etc etc, everything is in it ! You could also use these methods on "normal" integers, and thus avoid much of the algorithmic questions.

Solving ACM BigNumber Algorithmic problems with such a tool could become only a very basic Programming problem : calling the right method of the class. That might explain why Judges (at least UVA ones) do not allow to use this very class.

So allowing the full use of BigInteger class could kill part of the ACM Algorithmic challenge. Allowing a restricted set of methods (basics : + - % ^ << >>), with freely open sourcecode, could be fair, but much work for judges admin.

End of this post, aiming at runing the discussion anew, in order to get a reaction from the administrator about Java problem. Any reaction (from anybody) and advise REALLY welcome

Thanks for reading

[MAK]

Hello everyone,
I think the most important problem here is in the area of ease of use rather than speed. For most programs 10 seconds is more than enough. There are exceptions, but those are few and far between. I see no reason why BufferedReader should be restricted. It is the one of the first classes we learn how to use when we start with java. Making a function with System.in.read() is simply too much trouble for a beginner. Then there are the other issues already discussed in the thread - formatting, data-structures, sorting methods etc. Even Double.parseDouble() is not supported. In effect, a Java programmer has to end up writing his own library of useful methods and classes, many of which are already available to a C/C++ programmer. Many of my fellow CS students don't bother submitting to the OJ simply because it feels stupid to write a 100 line program for something that can be solved in 20 lines in JDK 1.5. Many Java programmers are turned away from the UVa OJ simply because they get compile errors every time they submit. Those who do get past that and find out the proper I/O methods, are still faced with the unavailablity of many standard tools. It almost seems to me that the authorities concerned are content with merely being able to claim that Java is supported at this OJ while not being worried about the quality of support they are providing. I can understand the need to restrict BigInteger and the like, but there is really no reason to make the life of a java programmer harder than it should be.

[Darko]

Ok, I have to post this thing...

I have a char[][] a, this gives me WA:

Code: Select all

a[tx][ty]++;

and this gives me AC:

Code: Select all

a[tx][ty] = (char)(a[tx][ty]+1);

Rather frustrating...

Oh, I forgot about this, it's even worse (while I'm here):
WA:

Code: Select all

String line = readLine() + readLine();

AC:

Code: Select all

String line1 = readLine();
String line2 = readLine();
String line = line1 + line2;

I kid you not. I have no idea what the difference between the two is. Probably gcj "optimizing" something, no clue.

Well, I might as well keep it in one place:
WA:

Code: Select all

long a = Math.round(d);

AC:

Code: Select all

long a = (long)Math.floor(d + 0.5);

And this one:
CE:

Code: Select all

while((line=readLine()).length()==0);

AC:

Code: Select all

while(true){
    line = readLine();
    if(line.length() > 0) break;
}

Btw, this works just fine:

Code: Select all

while((line=readLine()) != null)...

Dumtidum...

Darko

[pepak]

Did anyone try System.in.read(Byte[]) instead of System.in.read()? I found a curious problem - my application with System.in.read() works fine with the Judge. The same application with System.in.read(Byte[]) works fine locally, but the Judge complains about "wrong output" which I find somewhat strange. It almost looks like the Judge wants me to output the correct solution before I can read the next test case...

Makes me wonder whether I should strike back and just discover all valid results beforehand (I did find out a way to do it) and then write my application as

main() {
System.out.print("Test Case 1\nSolution is 5.\nTest Case 2.\nSolution does not exist\n");
}