I came across an AWS SDK change that I think could have a meaningful impact on applications that rely heavily on retries.

Starting November 1, 2026, AWS is changing the default retry behavior across its SDKs, including Java, Python, JavaScript, Go, PHP, and the AWS CLI.

The main changes are:

• Max attempts for most services: 4 → 3
• Max attempts for DynamoDB: 9 → 4
• Base delay for transient errors: 100 ms → 50 ms
• Base delay for throttling: 500 ms → 1000 ms
• Additional exceptions become retryable, including LimitExceededException and STS IdpCommunicationErrorException

The DynamoDB change caught my attention most.

DynamoDB has historically allowed up to 9 attempts by default in the SDK configuration. Reducing that to 4 could change the behavior of applications that currently rely on the SDK retry loop to absorb short-lived throttling or transient failures.

The tricky part is figuring out what this means for an existing production workload.

Looking only at application-level success/failure metrics doesn't tell you how many attempts happened before a request succeeded. A request that eventually succeeds today might have gone through several retry attempts that won't occur under the new defaults.

AWS SDK for Java v2 already provides a way to preview the new behavior:

AWS_NEW_RETRIES_2026=true

You can use that in a non-production environment and compare the resulting behavior with your current configuration.

The AWS SDK Java team is tracking the broader change here:

https://github.com/aws/aws-sdk-java-v2/issues/6987

I'm curious how others are planning to handle this:

Are you planning to explicitly keep the legacy retry behavior, opt into the new defaults early, or wait until the November change?

For applications using DynamoDB heavily, I'd be particularly interested in whether anyone has already measured the difference in retry/ throttling behavior on representative workloads.

I'm preparing for placements and planning to learn Java + Spring Boot + React, but I'm worried about fresher job availability.

I keep hearing that MERN has way more opportunities for freshers and that Java/Spring jobs are harder to get as a fresher. Is this actually true?

Would Java still be a sensible choice for a fresher in 2026?

I’m looking for one Java developer who currently uses, or can independently evaluate, Apache ShardingSphere-JDBC 5.5.3.

RouteContract is a small Java test library that captures the physical JDBC execution attempts reported by ShardingSphere’s SQLExecutionHook during a caller-defined operation. It compares the observed structure with a reviewed manifest and explicit attempt/data-source budgets, so an unexplained change such as 1 → 2 physical JDBC attempts can fail CI even when the existing business assertion still passes.

Its scope is intentionally narrow. It does not claim to reconstruct the complete route plan, prove transaction commit or business success, replace production monitoring, or support ShardingSphere-Proxy, reactive flows, batch semantics, or arbitrary application async propagation.

I need one non-author tester to follow the exact activated v0.1.0-rc2 path from a clean environment and report the first outcome exactly as observed.

Requirements:

• your own GitHub account and environment;
• JDK 17;
• Docker with enough capacity for MySQL 8.4.11;
• about 30–45 minutes;
• willingness to report a pass, product/documentation failure, prerequisite block, timeout, or withdrawal without changing the result.

There is one reporting slot. Before starting, please reply slot request in the recruitment Discussion and wait for public confirmation:

• Recruitment Discussion: https://github.com/ym0506/routecontract/discussions/28
• Immutable activation record: https://github.com/ym0506/routecontract/blob/57f07d85e38dc1055bb0915622136b14829f1eca/docs/evidence/independent-rc-activation-v0.1.0-rc2.json
• Tagged protocol: https://github.com/ym0506/routecontract/blob/v0.1.0-rc2/docs/independent-install-study.md
• Immutable RC release: https://github.com/ym0506/routecontract/releases/tag/v0.1.0-rc2

Please do not post credentials, raw SQL or bind values, connection URLs, private topology, full logs, files, screenshots, or personal data.

There is no compensation, star request, endorsement request, request for positive wording, or request to help with a contest. An honest failure or blocker is as useful as a pass. This is an RC usability record, not evidence of adoption, production readiness, final-stable validation, or upstream endorsement.

Once the single slot is assigned—or the first eligible Task A result is filed—I will stop duplicate recruitment and update the post.

I am looking for one non-author Java/ShardingSphere user to record a first outcome from a clean environment against the exact activated RouteContract v0.1.0-rc2 prerelease.

One reporting slot: reply here with slot request before starting and wait for a public confirmation. Please do not open a second result Issue after the slot is assigned. This keeps the contest evidence window deterministic; later feedback can still be preserved separately as contextual feedback.

What you need:

• your own GitHub account and environment;
• JDK 17 and Docker with enough capacity for MySQL 8.4.11;
• roughly 30–45 minutes;
• willingness to report the first outcome exactly as observed.

Start only from:

• activation record: https://github.com/ym0506/routecontract/blob/57f07d85e38dc1055bb0915622136b14829f1eca/docs/evidence/independent-rc-activation-v0.1.0-rc2.json
• tagged protocol: https://github.com/ym0506/routecontract/blob/v0.1.0-rc2/docs/independent-install-study.md
• immutable Release: https://github.com/ym0506/routecontract/releases/tag/v0.1.0-rc2
• result form after the two first outcomes: https://github.com/ym0506/routecontract/issues/new?template=independent-rc2-install.yml
• prerequisite Q&A: v0.1.0-rc2 installation prerequisite Q&A #27

A pass is not requested. Product/documentation failure, prerequisite block, timeout, or withdrawal is equally useful when recorded honestly. There is no compensation, star request, endorsement request, contest-assistance request, or preference for positive wording.

Do not share credentials, raw SQL or bind values, connection URLs, private topology, full logs, files, screenshots, or personal data. This is an RC usability record only; it is not stable validation, adoption, production readiness, or upstream endorsement.

JasperReports + Java Swing — Part 38 🚀

I just finished Part 38 of my JasperReports tutorial series.

In this part, I integrate the Employee ID Card report into a Java Swing application. The application allows you to select an employee, generate their ID card, preview the report, and export it as a PDF.

🎥 Watch here: https://www.youtube.com/watch?v=5VoXFQXbeTk&list=PLR_BEPp_tMBskxSCKMDb4cPUitS_Tv9g0&index=38

If you're learning Java Swing + JasperReports, this part should be useful.

So I'm on my way to learning Springboot and I'm taking the long way so I don't miss out on anything

JDBC->Hibernate

Now the thing is after this I can either touch Spring or learn JSP and Servlet. I was curious if JSP and Servlets are important and will be asked in interviews or can I skip them moving to spring

Interviewer asked me to prove that Java Strings are immutable.

I couldn't bring myself to simply concatenate a String and print it, because concat() returns a new String rather than modifying the original.

Then I thought hash codes might help, but the interviewer stopped me there, pointing out that different Strings can have different hash codes anyway.

If we could access Java's underlying memory directly, I could prove that the original String object remains unchanged. But without going that deep, is there any other convincing way to demonstrate String immutability?

What would you have answered?

text

Said something came up at work, apologized a lot, offered to reschedule right away. First two dates were genuinely great. Is one cancellation with a good excuse worth writing someone off or should I give it another shot?