A lightweight Windows utility that combines temp-folder cleanup with RAM-size-aware scripts so users can free disk clutter and nudge available memory without digging through system folders.
| Field | Details |
|---|---|
| Type | Windows desktop utility |
| Context | Personal Project |
| Role | Solo developer |
| Year |
| 2018 |
| Status | Completed personal release (v1.0) |
| Main focus | Temp cleanup, RAM profile selection, and scripted memory release |
CleanRam is a Java Swing desktop app I built in early 2019 while I was learning Java and desktop tooling on Windows. The idea was practical and narrow: give non-technical users a single window with three clear actions instead of hunting through %temp% folders or guessing which cleanup script fits their RAM.
The project is a personal utility, not a commercial product. I keep it in my portfolio because it shows how I approached a real machine problem with a simple GUI, file persistence, and small OS-level scripts, even when the implementation still reflects early Java habits I would refactor today.
On older or heavily used Windows PCs, temporary files pile up and background processes can make the machine feel sluggish. Many people know something is wrong but do not know which folders are safe to clear or how to run maintenance without breaking something.
%temp% and user temp paths fill with leftover installers, caches, and crash dumps.I designed and built the entire project end to end: the main window and RAM selection dialog in NetBeans Form Editor, recursive temp deletion in Java, persistence of the user's RAM choice under %APPDATA%, and a set of VBE helper scripts scaled from 1 GB through 128 GB. I also packaged the app as a runnable JAR and wrote the project README.
CleanRam opens a fixed-size Spanish-language window with three large actions. Users first configure how much RAM their PC has, then they can run a matching cleanup script or wipe the Java temp directory from the same UI.
cscript.Cleanram.jar from the NetBeans dist output.A dedicated dialog lets the user pick one of ten memory tiers. The selection is written to a small text file so the main window can run the right script later without asking again.
if(i==0){
a.Escribir(arcf, "1");
}
// ... tiers through 128 GB ...
JOptionPane.showMessageDialog(null, "Se ha configurado el tamaño de RAM correctamente","CleanRam",JOptionPane.INFORMATION_MESSAGE);I chose file-based persistence instead of registry keys because it was easy to debug as a beginner and kept the logic visible on disk.
The clear-temp action walks the JVM temp directory recursively and deletes files and nested folders before showing a confirmation dialog.
public void borrarDirectorio(File directory){
File[] ficheros = directory.listFiles();
for(int x=0;x<ficheros.length;x++){
if (ficheros[x].isDirectory()){
borrarDirectorio (ficheros [x]);
}
ficheros[x].delete();
}
}I surfaced a short "Eliminando..." label during the operation so the UI did not feel frozen even though the work is synchronous.
Each RAM tier maps to a VBE file that sets a Mystring buffer sized for that memory class. Java reads the saved tier and executes the matching script.
linea = br.readLine();
if(linea=="4")
Runtime.getRuntime().exec( "cscript com/giusniyyel/cleanram/v1/util/free4gb.vbe");The scripts stay outside the JAR so I could tune sizes without recompiling the UI, at the cost of fragile working-directory assumptions.
The app is a standard NetBeans Ant project targeting Java 8. The entry point is CleanRam_es, built with Swing and the Nimbus look and feel. I split responsibilities across three Java classes: the main frame for actions, CleanRam_es_TM for RAM selection, and Archivo for read/write of the profile file.
Persistence lives under the user's %APPDATA% tree. The RAM dialog writes a numeric code (1, 2, 4, … 128) to ramsize.txt. The main window checks that the file exists before attempting a RAM release; if it is missing, the user gets a direct error asking them to configure RAM first.
OS integration uses Runtime.getRuntime().exec() to call cscript on the bundled .vbe files. Temp cleanup uses System.getProperty("java.io.tmpdir") rather than hard-coded drive letters, which keeps that path portable across user accounts. A separate freetemp.bat in the util folder targets classic Windows temp locations for manual or alternate use.
There is no automated test suite and no installer pipeline in this version. Distribution is the built JAR plus bundled util assets, as described in the dist notes.
I optimized for clarity over flexibility: three large image buttons on a 1024×600 layout, Spanish copy, and modal dialogs for every outcome.
TM, LR, LC) so actions are recognizable at a glance.%APPDATA% paths, and cscript assume Windows; the app was never meant to run cross-platform.com/giusniyyel/cleanram/v1/util/..., which breaks easily if the JAR is launched from another folder.GiusNiyyel\CleanRam while the reader looks for giusniyyel\cleanram, which can prevent the release action from finding the saved profile on case-sensitive comparisons.Archivo.Leer: using == on linea from BufferedReader is unreliable in Java; .equals() would be the correct check.Building CleanRam taught me how desktop apps bridge user intent and OS behavior. I had to think about where files live on a real machine, how to bundle helpers with a JAR, and how to communicate errors in plain language instead of stack traces.
This project is no longer actively maintained. Version 1.0.0 is a completed personal release I built while learning Java, and I treat it as stable but dated. I keep it in my portfolio as an honest snapshot of early desktop work, not as production system software.
== string checks with .equals() and add basic unit tests around Archivo read/write.%APPDATA% folder casing and resolve script paths from the JAR classpath or ProcessBuilder with absolute paths.