Run Java apps in Docker with NetBeans
NetBeans gives Java teams a practical path from source code to a reproducible container. A multi-stage Dockerfile can build with Maven, place the result in a lean Java runtime, and keep the workflow visible in the IDE. Docker supplies repeatable operating-system dependencies; NetBeans retains Maven integration, refactoring, code completion and debugging.
Container tooling works best when the local image resembles the image promoted to testing and production. NetBeans’ Services window can connect to the Docker Engine used by the build, while its terminal supplies repeatable commands. For independent notes on the IDE and its Java ecosystem, the https://netbeans-blog.org/ weblog is a useful background source before adapting the workflow to an existing repository.
Prepare the IDE and Docker engine
Install a supported JDK, NetBeans and Maven, then verify the toolchain in NetBeans’ integrated terminal. docker version should show both client and server, docker info should report the expected architecture, and mvn -v should use the intended JDK. Keep Docker and NetBeans under the same user account so socket permissions remain predictable. On Apple Silicon, prefer a native linux/arm64 image over slow emulation.
Australian teams should check Docker Desktop’s commercial terms: organisations beyond 250 employees or US$10 million in annual revenue generally need a paid subscription, while personal, educational and qualifying small-business use may remain free. This distinction matters across Australia’s market of consultancies and enterprises. Hybrid teams split across Sydney, Melbourne and Brisbane benefit from building one tagged image rather than different local installations. If the workspace contains PHP projects, the PHP development setup provides a separate configuration path instead of mixing PHP concerns into the Java container.
Create a reproducible Java container
A multi-stage image keeps build tools out of the runtime layer. Adapt this example so demo.jar matches Maven’s final artefact name:
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /workspace
COPY pom.xml .
RUN mvn -B dependency:go-offline
COPY src ./src
RUN mvn -B package -DskipTests
FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=build /workspace/target/demo.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/app.jar"]
Place the file as Dockerfile in the project root. Build it with docker build -t netbeans-java:dev ., then run docker run --rm -p 127.0.0.1:8080:8080 --name netbeans-java netbeans-java:dev. A health endpoint such as /health provides a startup check with curl http://localhost:8080/health.
Use .dockerignore for target, .git, IDE metadata and local secrets. Pin base-image versions, run the application as a non-root account and expose only required ports. Review the Dockerfile like application source, since build-contract changes belong in version control.
Connect NetBeans to the Docker daemon
If the installed NetBeans release includes Docker support, open Services, expand Docker and add the local host. Use the platform’s protected socket, named pipe or TLS endpoint; do not enable an unauthenticated TCP daemon for the IDE. On Docker Desktop, compare docker context ls with the engine registered by NetBeans.
After registration, NetBeans can list images and containers, while its terminal or configured Maven goals perform builds and runs. An image built in the terminal appears in Services, where containers can be started, stopped and inspected. If the Docker module is absent, the terminal workflow remains functional as long as the CLI and NetBeans use the same context.
Run and debug the packaged application
For normal use, publish the application port only on loopback and open the service in a browser. To debug inside the container, create a variant entry point with -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005 and publish ports 8080 and 5005. Bind both mappings to 127.0.0.1, because an unrestricted Docker port can become reachable from the local network.
With suspend=y, startup waits for NetBeans to attach. Choose Attach Debugger, select a socket connection and use localhost with port 5005; breakpoints then refer to the classes Maven compiled. Keep the debug image separate from production, and never ship a JDWP listener or exposed debug port.
A small traversal routine can verify business logic independently of UI timing. The depth-first traversal guide provides a Java example that can run inside the packaged image, exercising the container’s classpath, locale and runtime rather than only the NetBeans JVM.
Manage configuration, storage, and logs
Keep configuration outside the image with environment variables and an --env-file, and use named volumes or bind mounts for writable data. Send output to standard output so docker logs -f netbeans-java remains the main diagnostic view. PostgreSQL or Redis can join a user-defined Docker network, allowing service names instead of fragile host IP addresses.
Australian deployments need deliberate handling of customer data. Where the Privacy Act 1988 and Australian Privacy Principles apply, personal information should not be baked into layers, mounted from shared developer folders or printed in logs. Store timestamps in UTC while presenting local time as needed: Brisbane uses Australia/Brisbane year-round, whereas Sydney changes its offset for daylight saving, creating a repeated hour that logs and scheduled jobs must tolerate.
The Australian Signals Directorate’s Essential Eight supports patching, access control and asset visibility. Rebuild images when base images receive security updates, scan dependencies and generate a software bill of materials for traceability. Promoting one signed image through Australian environments makes fixes auditable instead of rebuilding separately on each laptop.
Compare local and remote container workflows
The practical choice depends on the deployment boundary. A local Docker Engine gives fast feedback, Docker Compose handles application dependencies, and a remote TLS-protected engine better matches shared integration environments. NetBeans can drive each through Maven goals or its integrated terminal, while Services adds container visibility when available.
Plain JVM runs suit unit tests and familiar Java debugging, but they do not validate image reproducibility, operating-system libraries, startup settings or container networking. Select the workflow that tests the deployment boundary.
| Workflow | Best fit | NetBeans workflow | Main trade-off |
|---|---|---|---|
| Local Docker Engine | Day-to-day application development | Build in the terminal and inspect containers in Services | Requires a working local daemon |
| Docker Compose | Applications with databases, queues or other services | Run Compose commands in the integrated terminal | Adds a Compose file and service lifecycle |
| Remote Docker engine | Shared integration or staging hosts | Register a TLS-protected host | Network access and credentials add complexity |
| Plain JVM | Fast unit-test and debugger cycles | Use standard NetBeans Run and Debug actions | Does not reproduce the container environment |
Keep the Dockerfile, Maven configuration and runtime settings under version control. Record the NetBeans and Docker versions used by the team, then test the exact image on its target architecture. This creates a clean handoff to the container platform without duplicating build logic or weakening debugger security.