The Java Buildpack doesn't support the use of .profile.d
scripts for startup. The buildpack creates very complex command lines like the following
CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-2.0.1_RELEASE -memorySizes=metaspace:64m.. -memoryWeights=heap:75,metaspace:10,native:10,stack:5 -memoryInitials=heap:100%,metaspace:100% -totMemory=$MEMORY_LIMIT) && JAVA_OPTS="-Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh $CALCULATED_MEMORY -agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n" && SERVER_PORT=$PORT eval exec $PWD/.java-buildpack/open_jdk_jre/bin/java $JAVA_OPTS -cp $PWD/.:$PWD/.java-buildpack/spring_auto_reconfiguration/spring_auto_reconfiguration-1.10.0_RELEASE.jar org.springframework.boot.loader.JarLauncher
that address everything from memory region allocation, error handling, supported features (debugging in this case), classpath, etc. Because this command line is essential to the expected function of Java applications on the platform, overriding it with other startup scripts, while possible, is not something we support.
As you point out in the beginning of your post, the buildpack runs your application without this script, which is our goal; a user should be able to push an application and "it just works". If there's something about your application that prevents it from properly operating in a Cloud Foundry environment, I encourage you to open an issue against the buildpack so that we can address it.
To address the issue at hand, the failure of a health check in Cloud Foundry generally means that application is not accepting HTTP connections on the port designated by the container. You need to ensure that your application listens on the port indicated by $PORT
when it starts.