Eduard Gomoliako Gems

Error in user YAML: (<unknown>): mapping values are not allowed in this context at line 2 column 70

---
name: ste
description: Write prose in Simplified Technical English (ASD-STE100): short, direct, unambiguous sentences.
keep-coding-instructions: true
---

Output Style: Simplified Technical English

Use the principles of ASD-STE100 Simplified Technical English for all prose. Target approximately 80% compliance with its writing discipline, not its restricted vocabulary.

Non-Null vs. Nullable by Default in Java: Industry Trends and Arguments

Background: Java’s Nullability Problem

Java historically treats all object references as potentially null by default – there is no built-in way in the type system to indicate whether a variable can or cannot be null . This implicit “nullable by default” design has led to the infamous NullPointerException (“billion-dollar mistake” as Tony Hoare called it ) when null values aren’t handled properly. For decades, developers had to rely on documentation, runtime checks, or patterns like returning sentinel values/Optional to signal absence of a value .

To improve safety, the Java ecosystem introduced nullability annotations (e.g. @Nullable, @NonNull/@NotNull) and static analysis tools. However, a key question arises: should we assume types are non-nullable by default (requiring explicit annotation of

The Power of Ten – Rules for Developing Safety Critical Code

Author: Gerard J. Holzmann
Institution: NASA/JPL Laboratory for Reliable Software
Location: Pasadena, CA 91109

Introduction

JSpecify nullness design FAQ

As JSpecify is still in early stages, the link you followed has brought you to a draft document, which we are using for ease of editing. In the unspecified future this will become markdown hosted at jspecify.org, and as we update links we will make them into deep-links to the appropriate section (sorry that for now you were brought only to the top).

Project members: please edit at will; comment only if unsure of a change.

Can’t you see that nullness annotations are ugly, and we’d be better off with a String? language feature like Kotlin has?

Yep.

	import nl.altindag.ssl.SSLFactory; // io.github.hakky54:sslcontext-kickstart

	@NoArgsConstructor
	public class HttpClientConfigurerTrustAllCACerts implements HttpClientConfigurer {

	@Override
	@SneakyThrows
	public void configureHttpClient(HttpClientBuilder clientBuilder) {

	// val sslContext = SSLContexts.custom().loadTrustMaterial(null, (cert, authType) -> true).build();

	package camel.test;

	import lombok.SneakyThrows;
	import lombok.val;
	import org.apache.camel.EndpointInject;
	import org.apache.camel.Produce;
	import org.apache.camel.ProducerTemplate;
	import org.apache.camel.builder.RouteBuilder;
	import org.apache.camel.component.mock.MockEndpoint;
	import org.apache.camel.test.junit5.CamelTestSupport;

	class Accessor {
	private static final MethodHandle methodHandle;

	private static final String METHOD_NAME = "methodName";

	static {
	try {
	val declaredMethod = Target.class.getDeclaredMethod(METHOD_NAME);
	declaredMethod.setAccessible(true);

	#!/usr/bin/env bash

	LOG_FILE=/dev/null

	exec > >(tee -a $LOG_FILE >&1)
	exec 2> >(tee -a $LOG_FILE >&2)

	if [ -n "$GIT_COMMITTER_DATE" ]; then
	FST="--faked-system-time $(date -j -f '%Y-%m-%dT%H:%M:%S' $GIT_COMMITTER_DATE +'%s')"
	fi

	#!/usr/bin/env bash

	TMP_FILE=/tmp/docker-compose.$$.yaml

	finish() {
	rm ${TMP_FILE} ${TMP_FILE}.tmp 2>/dev/null
	}

	trap finish EXIT

	server {
	listen 80;
	server_name ~^(?<domain>.+)$;

	set $htdocs "/usr/local/var/www/$domain/";

	root $htdocs;
	index index.html;

	set $auth "off";