Skip to content

Fix Java and C lesson code execution (partial fix) - #65

Open
umarjaved204 wants to merge 3 commits into
QuantumLogicsLabs:mainfrom
umarjaved204:fix/learn-code-execution
Open

umarjaved204 wants to merge 3 commits into
QuantumLogicsLabs:mainfrom
umarjaved204:fix/learn-code-execution

Conversation

@umarjaved204

Copy link
Copy Markdown

Summary

Fixes errors in Java and C lesson code ("Try and Learn"). This is a partial fix: see "Not included" below.

What is fixed

  • Java class names: code now runs whatever the class is named (Main, HelloWorld, etc.), not only Solution. package lines also work.
  • Java input: programs using Scanner now get the learner's input instead of hanging for 8 seconds.
  • Timeouts: Java, C and C++ now show "Execution timed out after 8s" instead of "exited with code null".
  • Missing Java: if the JDK is not installed, the learner gets a clear message. Before, the error was not handled, and on a long-running Node server this stopped the whole process.
  • C compiled as C++: C now uses gcc instead of g++, so normal C code (int *p = malloc(n), a variable named new) compiles. math.h is linked.
  • Random failures on Windows: starting a freshly built program is retried when antivirus briefly locks it (spawn EPERM, about 2 in 15 runs before).
  • Leftover files: failed builds now delete their binaries. 12 old run_*.cpp files removed from the repo, and src/runtime/tmp is now in .gitignore.
  • Java, C and C++ now use getWritableRuntimeDir() (/tmp on Vercel), like the Ruby runner.

Not included

  • The live site (Vercel) still cannot run Java, C or C++. Vercel has no JDK or C/C++ compilers. With this PR, learners there get a clear "not installed" message instead of a 500 "read-only file system" error, but the code still does not run. This needs a hosting decision (self-hosted Piston, a paid service, or a separate server).
  • Challenges (src/routes/challenge.js) still skip Java and C++ on purpose. The Java/C++ test drivers there also add the learner's code twice, so they need their own fix after the hosting decision.

Testing

No automated tests exist in the repo, so I tested by running code through playgroundService.executeCode():

  • Java: 12/12 cases pass, including class names, nested classes, package, Scanner input, timeout, compile errors, and JDK missing from PATH (server stays up).
  • C and C++: 10/10 pass, including malloc, a variable named new, sqrt, scanf, compile errors and timeout.
  • 30 C runs in a row: 0 failures.

Please test before merging: one C++ lesson that uses <iostream>. C++ was only tested with <cstdio> programs.

- Detect the learner's public/main class instead of forcing the class to
  be named Solution, so lessons using `public class Main` compile and run.
  Package declarations are supported too.
- Accept stdin and close the child's stdin, so Scanner-based lessons get
  their input instead of blocking until the 8s timeout.
- Report timeouts with a clear message instead of "exited with code null".
- Handle spawn errors on javac/java. Previously a missing JDK emitted an
  unhandled 'error' event and terminated the Node process; it now returns
  a "Java (JDK) is not installed" message like the C++ runner does.
- Use getWritableRuntimeDir() so serverless hosts reach the JDK check
  instead of failing on a read-only filesystem.
C submissions were written to a .cpp file and compiled with g++, so valid
C was judged by C++ rules: `int *p = malloc(n)` failed with "invalid
conversion from void*", and C identifiers such as `new` or `class` were
syntax errors. C now has its own runner using gcc (linked with -lm so
math.h works).

The C and C++ runners share one compile-and-run implementation, which
also:
- deletes the binary when compilation fails (a failed link could leave
  a partial executable behind)
- reports timeouts with a clear message instead of "exited with code null"
- retries spawning a freshly linked binary on EPERM/EBUSY, which Windows
  antivirus causes intermittently (~2 in 15 runs locally)
- uses getWritableRuntimeDir() like the Ruby runner
Remove twelve leftover run_*.cpp files (learner code from earlier runs)
from src/runtime/tmp and ignore the directory, keeping it in the repo
with a .gitkeep. app.log is left tracked as before.
@vercel

vercel Bot commented Sep 19, 2026

Copy link
Copy Markdown

@umarjaved204 is attempting to deploy a commit to the seno-quantum-coder's projects Team on Vercel.

A member of the Team first needs to authorize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant