July 23, 2026 • 21 mins
A guide designed for experienced programmers to quickly master modern Java. The text emphasizes productivity and speed, bypassing historical versions to focus on the language's state as of the Java 9 release. It covers essential programming structures, including primitive types, variables, and control flow, while introducing the JShell interactive tool. The documentation outlines core concepts such as object-oriented programming, inheritance, lambda expressions, and the module system. Additionally, the preface notes that the book prioritizes server-side and Android development by omitting legacy desktop user interface topics. Overall, these pages serve as a technical roadmap for navigating the libraries and syntax of contemporary Java.
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Core-Java-SE-9-Impatient-ebook/dp/B075MJ5QV8?&linkCode=ll2&tag=cvthunderx-20&linkId=130fc1cc4b4ede16368d6c28403ebf39&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cyber_security_summary
Get the Book now from Amazon:
https://www.amazon.com/Core-Java-SE-9-Impatient-ebook/dp/B075MJ5QV8?&linkCode=ll2&tag=cvthunderx-20&linkId=130fc1cc4b4ede16368d6c28403ebf39&language=en_US&ref_=as_li_ss_tl
Discover our free courses in tech and cybersecurity, Start learning today:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
If you ask a modern supercomputer today to calculate two
point zero minus one point one, it actually gets the
answer wrong.
Speaker 2 (00:08):
Yeah, it completely fails.
Speaker 1 (00:09):
Right, it won't give you zero point nine, It'll spit
out zero point eight nine, nine nine, just stretching out
until it finally gives up, which is wild, right it is,
And welcome to the deep dive. Today, we're exploring why
the most powerful machines on are still struggle with you know,
grade school arithmetic.
Speaker 2 (00:25):
And more importantly, how we navigate those limits as developers.
Speaker 1 (00:29):
Exactly, So for you the listener, we are taking on
a highly targeted mission.
Speaker 2 (00:33):
Today.
Speaker 1 (00:33):
We are unpacking excerpts from Core Jama Se nine for
the Impatient, second Edition by K. S.
Speaker 2 (00:40):
Horseman, which is such an essential read because I mean,
Java is over two decades old.
Speaker 1 (00:45):
Yeah, it's ancient in tech years, right.
Speaker 2 (00:47):
The ecosystem is just burdened by these layers of legacy architecture.
If you pick up a traditional textbook, you're looking at
thousands of pages dwelling on.
Speaker 1 (00:56):
Ancient history, making you trace the lineage of archaic libe
before you can even write a basic concurrent application.
Speaker 2 (01:04):
Exactly. It's exhausting.
Speaker 1 (01:05):
So our mission today is to cut through all of
that noise. We're extracting the modern practical tools introduced in
Java nine, so you can skip the computer science theory
of the nineteen nineties.
Speaker 2 (01:15):
It's straight to building scalable server side systems.
Speaker 1 (01:19):
But you know, to appreciate the modern workarounds Java nine
gives us, we first have to establish why we're still
building on top of this twenty year old foundation at all.
Speaker 2 (01:28):
Right, because in the fast paced tech world, twenty years
is basically the Mesozoic era.
Speaker 1 (01:34):
Seriously, yet Java is still everywhere. Why is that?
Speaker 2 (01:37):
Well, the survival of the language really comes down to
its initial architectural promise, which is the Java Virtual Machine
the JVM.
Speaker 1 (01:44):
Okay, let's unpack this.
Speaker 2 (01:45):
Prior to this paradigm, if a developer wrote a program,
that code had to be compiled specifically for the underlying hardware.
Speaker 1 (01:52):
Architecture, like physically tied to the machine.
Speaker 2 (01:55):
Yes, you needed a distinct compilation for a Windows environment,
another for a Mac and yet another for a Linux server.
Speaker 1 (02:02):
Which sounds like a nightmare it.
Speaker 2 (02:04):
Was, But Java decoupled the software from the physical hardware.
You compile your source code once into an intermediate state
called bytecode.
Speaker 1 (02:13):
A universal instruction set basically exactly which.
Speaker 2 (02:16):
The JVM then takes over. As long as the device
has a JVM installed, it can interpret that bytecode on.
Speaker 1 (02:22):
The fly, so it translates the intermediate instructions into the
specific machine code of the host device.
Speaker 2 (02:28):
Right, whether that's a high frequency trading server or I
don't know, a smart refrigerator. Oh wow. Yeah, that decoupling
is why massive enterprise back ends and Android ecosystems are
entirely reliant on it today.
Speaker 1 (02:41):
Right, once run anywhere. It was a brilliant design, it
really was. But you know, to achieve that massive enterprise
level scale, Java developed a reputation for being heavily bureaucratic.
It's incredibly verbose.
Speaker 2 (02:53):
Oh. Absolutely.
Speaker 1 (02:53):
To appreciate the first massive shift in Java nine, we
have to look at the classic Hello.
Speaker 2 (02:58):
World program rite a passage.
Speaker 1 (03:00):
Right in almost any other scripting language, if you want
to output a string of text to the console, you
invoke a print command and you're done.
Speaker 2 (03:08):
But traditional Java demands a rigid structural hierarchy before it
will execute a single command.
Speaker 1 (03:14):
Yeah, you have to wrap everything. In an object oriented paradigm,
you declare a public class, allocate a name space inside.
Speaker 2 (03:21):
That class, you declare a public static void main.
Speaker 1 (03:24):
Method cassing it and array of string arguments. Only then
can you call system dot out, dot printle in.
Speaker 2 (03:30):
It's a lot of overhead.
Speaker 1 (03:31):
It's like imagine wanting to fry a single egg for breakfast,
but the environment insists that before you turn on the stove,
you must zone a commercial plot, build a fully permitted
stainless steel kitchen, and pass a municipal health inspection.
Speaker 2 (03:46):
That is Yeah, that's a perfect analogy. It's a phenomenal
structure if you're running a massive restaurant franchise, but it's
deeply punishing if you just want to test a single
line of code. Right, and that uniformity of forcing everything
into a class hierarchy is what makes million line code
bases comprehensible. Sure, but as you pointed out, the friction
for experimentation is incredibly high. So Java nine addresses this
(04:08):
directly by introducing jshell.
Speaker 1 (04:11):
The jshell revolution exactly.
Speaker 2 (04:13):
It's an r epl or reevaluate print loop. You open
a terminal type jshell and you're dropped into a live,
interactive environment.
Speaker 1 (04:20):
Okay, I want to look under the hood here, because
JAMA is a strictly compiled language. Right, You can't just
run raw Java code like it's a Python script. If
I'm sitting in jshall and I just type, you know,
quote hello world, unquote dot length. How is the JVM
executing that without me running a compiler first.
Speaker 2 (04:39):
Well, what's fascinating here is jshell actually leverages the compiler
api introduced in earlier versions of Java. Okay, when you
type that single snippet and hit enter, jshell secretly takes
your fragment of code and wraps it in a synthetic
invisible class.
Speaker 1 (04:54):
Wait really it does that automatically.
Speaker 2 (04:56):
Yep. It runs at synthetic class through the Java compiler
entirely in the system's memory bypassing the hard drive completely.
Speaker 1 (05:02):
Oh wow.
Speaker 2 (05:03):
It manages the class pack dependencies, dynamically loads the resulting
bytecode into the running JVM, executes it, and prints the
result back to your terminal.
Speaker 1 (05:11):
So it is doing all of that boilerplate commercial kitchen
construction invisibly in the background, in milliseconds.
Speaker 2 (05:18):
Exactly, giving you the illusion of an interpreted scripting language.
Speaker 1 (05:22):
That's credible.
Speaker 2 (05:23):
The environment even maps your live session state. If you
declare an integer variable x, jshell keeps that variable alive
in memory for the duration of the seession, allowing you
to manipulate it in subsequent lines.
Speaker 1 (05:36):
That fundamentally alters the development workflow totally.
Speaker 2 (05:39):
Instead of setting up a heavy ide and fighting with
build tools just to see how a specific method behaves,
you test the logic instantly.
Speaker 1 (05:46):
It encourages a sandbox approach, and once you have this
instant feedback loop in jshell, I feel like the very
first thing a developer usually tests is mathematical logic.
Speaker 2 (05:56):
Which brings us back to that supercomputer failing its subtraction.
Speaker 1 (05:59):
Yes, when I ask jshell to calculate two point zero
minus one point one, the output is that trailing string
of nines zero point eight nine nine nine nine. Why
doesn't the language just fix this? Why not make everything
infinitely precise automatically. I mean, we aren't dealing with the
simple software bug here.
Speaker 2 (06:18):
Right, No, not at all. This is a fundamental limitation
of hardware architecture. We are hitting the constraints of the
IE seven five y four standard for floating point arithmetic.
Speaker 1 (06:29):
Okay, break that down for us.
Speaker 2 (06:30):
Well. Human beings calculate in base ten, where fractions like
one tenth have a clean definitive representation, but computers operate
in base two binary logic, mapping data into fixed physical
memory blocks.
Speaker 1 (06:43):
So a standard double precision floating point number in Java
a double is allocated exactly sixty four bits of physical
memory space.
Speaker 2 (06:52):
Yes, the CPU divides those sixty four bits into a
specific structure one bit for the sign, eleven bits for
the exponent, and fifty two bits for the main time
or the significant digits. Got it. When you ask the
CPU to represent the base ten fraction of one tenth
in binary, it becomes a repeating infinite sequence of zeros
and ones.
Speaker 1 (07:09):
Similar to trying to write out one third as a decimal.
You get zero point three three three, and eventually you
just run out of paper and have to stop writing.
Speaker 2 (07:16):
Exactly The sixty four bit memory block is the edge
of the paper. The CPU literally runs out of physical
transistors to hold the infinite binary sequence, so it truncates it.
It chops off the end, which introduces a microscopic roundoff.
Speaker 1 (07:30):
Error, and when the system converts that truncated binary value
back into base ten for your terminal screen, the missing
precision reveals itself as that endless string of nine or feislely. Now,
if you are building a physics engine for a video game,
a microscopic roundoff error doesn't matter.
Speaker 2 (07:46):
No nobody notices.
Speaker 1 (07:47):
But if I'm writing a financial ledger application, I cannot
lose fractions of ascent on every transaction. I need exact precision.
Speaker 2 (07:54):
Right, which is illegal in some context.
Speaker 1 (07:56):
Honestly, I assume this means Java forces developers to choose
between hardware speed and mathematical accuracy.
Speaker 2 (08:02):
That is, the exact tradeoff. Primitive types like double end
float are blazingly fast because they map directly to the
CPU's native instruction set.
Speaker 1 (08:10):
They execute in a single clock cycle.
Speaker 2 (08:12):
Right. But if you require absolute precision for financial math,
the text explicitly warns against primitive types, you must invoke
the big decimal class.
Speaker 1 (08:22):
Which bypasses the CPU's native floating point logic entirely exactly.
Speaker 2 (08:27):
Big decimal is an object. It implements arbitrary precision arithmetic
and software.
Speaker 1 (08:31):
Oh so it handles the math itself.
Speaker 2 (08:33):
Yeah, It dynamically allocates as much heat memory as necessary
to store the exact decimal representation of the number it
guarantees zero point nine.
Speaker 1 (08:42):
But the cost is performance because every mathematical operation requires
object instantiation, method dispatch, and eventual garbage collection.
Speaker 2 (08:51):
Yes, it's an active architectural choice the developer has to make.
Speaker 1 (08:54):
And this hardware limitation applies to whole numbers as well.
Speaker 2 (08:57):
Right, oh, absolutely.
Speaker 1 (08:58):
The text highlights a terrified trap with standard integers. If
you take a standard integer variable and assign up the
value of one billion, and then multiply it by three,
you don't get three billion.
Speaker 2 (09:08):
No, you don't.
Speaker 1 (09:09):
Java quietly outputs negative one billion, two hundred and ninety
four million, nine hundred and sixty seven thousan two hundred
and ninety six. The logic just violently inverts.
Speaker 2 (09:18):
It's crazy. So a standard in in Java is allocated
thirty two bits of memory space and a two's complement
binary representation, which is how modern processors handle signed integers.
The maximum positive value you can fit into those thirty
two bits is just over two billion.
Speaker 1 (09:33):
Because the leftmost bit, the thirty second bit, is reserved
as the sign bit.
Speaker 2 (09:37):
Right. If it's a zero, the number is positive. If
it's a one, the CPU interprets the entire sequence as
a negative number.
Speaker 1 (09:45):
So when you multiply one billion by three, the resulting
binary sequence is too large for the thirty one bits
allocated for the magnitude exactly.
Speaker 2 (09:53):
The binary logic overflows, spilling a one into that thirty
second sign big position. Ah. I see the CPU you
blindly follows its architecture. It sees a one in the
sign position and interprets the resulting garbled sequence as a
massive negative number.
Speaker 1 (10:08):
What makes this uniquely dangerous and traditional Java is that
the multiplication operator the standard asterisk, does this silently.
Speaker 2 (10:15):
That's the worst part. It doesn't warn you.
Speaker 1 (10:17):
The binary spills over the sign flips, and your e
commerce application suddenly thinks a customer ordering three billion dollars
worth of inventory actually has a negative balance.
Speaker 2 (10:26):
Effectively owning the money. It is a silent data corruption.
Speaker 1 (10:30):
So what's the modern Java solution for this? Well?
Speaker 2 (10:32):
Java nine offers a targeted solution in the math library.
Instead of relying on the native multiplication operator, you invoke
math dot multiplay exact.
Speaker 1 (10:41):
Oh okay. Does it allocate more memory to hold the
larger number.
Speaker 2 (10:45):
No, it retains the thirty two bit limitation, but it
actively monitors the operation. Math dot multiply exact bridges the
high level language and the low level CPU logic a soo.
It either checks the hardware's internal overflow flag or simulates
the boundary check. If the calculation exceeds the physical memory limit,
it intercepts the operation and throws an arithmetic.
Speaker 1 (11:07):
Exception, so it crashes the program on purpose. Exactly, it
forces a loud failure rather than permitting a silent corruption,
which is much safer. So primitive math is strictly bound
by the physical architecture of the CPU registers. But if
you think numbers are fragile in memory, the way Java
handles human language is a completely different level of complexity.
Speaker 2 (11:27):
Oh, mathematical logic is universal human language, and the character
encodings required to render it are cultural artifacts mapped onto
physical memory.
Speaker 1 (11:35):
That's a great way to put it. The text introduces
the string class and drops a massive warning right away
regarding conditional logic. It says never use the double equals
operator to compare two strings.
Speaker 2 (11:48):
It causes bugs that can take days to track down
because occasionally using double equals actually works.
Speaker 1 (11:56):
Which creates a false sense of security. Exactly, pack the
pointer mechanics here, because this is where the logic breaks
down for developers coming from languages like Python. The double
equals operator in Java doesn't care about the text itself.
It is evaluating the hexadecimal memory address.
Speaker 2 (12:13):
It's asking do these two variables point to the exact
same physical location in the heap.
Speaker 1 (12:18):
Whereas the dot equals method forces the JVM to travel
to those memory addresses and iterate through the underlying character arrays,
comparing them bite by bite to see if the contents match.
Speaker 2 (12:29):
Right, But you mentioned it sometimes works. Yeah.
Speaker 1 (12:31):
If I define a string ex's hello and why is
hello and use double equals, Java might actually return true.
Why would it do that if there are separate variables?
Speaker 2 (12:39):
So the JVM implements a memory optimization technique called string
in turning. Okay, Because strings are immutable in Java, meaning
they cannot be changed what's created, The JVM maintains a
string pool in the.
Speaker 1 (12:52):
Heap, a pool of existing strings.
Speaker 2 (12:54):
Right, if you declare a string literal hello, the JVM
checks the pool. If Hello already exists. It doesn't allocate
new memory. It simply points your new variable to the
existing memory address.
Speaker 1 (13:08):
So, in that specific scenario, double equals returns true because
both variables point to the identical address exactly.
Speaker 2 (13:14):
But the second you manipulate the text, say you extract
a substring or dynamically a panda character, the JVM is
forced to allocate a completely new memory address for the result, and.
Speaker 1 (13:24):
At that point double equals returns false, even if the
resulting text looks identical on the screen.
Speaker 2 (13:29):
Yep, it's comparing two different hecks addresses. You are bypassing
the intern pool. If you don't understand the pointer mechanics,
the behavior appears entirely erratic.
Speaker 1 (13:38):
Here's where it gets really interesting. The illusion of text
goes even deeper when we examine the chart type.
Speaker 2 (13:43):
Oh, this is fascinating.
Speaker 1 (13:44):
This forces us to look at the historical context of
Java's architecture. Java was designed in nineteen ninety one, during
a period of complete chaos in character encoding.
Speaker 2 (13:54):
Total chaos. You had to ask you for English, which
used seven bits, but Western European languages used different and
eight bit extensions. Russian had KOI eight Japanese had shift jis.
Speaker 1 (14:04):
None of them were compatible.
Speaker 2 (14:06):
No, a text file created in Tokyo looked like pure
gibberish on a terminal in London.
Speaker 1 (14:11):
So the industry solution was the Unicode standard, and in
nineteen ninety one the architects of Unicode decided that a
sixteen bit standard would be sufficient.
Speaker 2 (14:19):
Right, sixteen bits gives you exactly sixty five, five hundred
and thirty six available character slots.
Speaker 1 (14:24):
At the time that seemed infinitely large. They assumed it
could comfortably hold every alphabet and symbol.
Speaker 2 (14:29):
On Earth, and Java was built from the ground up
to natively support this new sixteen bit Unicode standard. The
foundational char primitive type in Java was permanently defined as
a sixteen bit block of.
Speaker 1 (14:40):
Memory, which became a catastrophic legacy trap because sixty five
thousand slots was nowhere.
Speaker 2 (14:45):
Near enough, not even close. By the time they incorporated
comprehensive Chinese ideographs, obscure historical scripts, and complex mathematical formatting,
the Unicode Consortium blew right past the sixty five thousand
limit they ran. Yeah, they were forced to expand Unicode
to a twenty one bit standard, which supports over a
(15:05):
million characters.
Speaker 1 (15:06):
But Java's architecture was already set in stone. A Java
string is essentially an array of these sixteen bit char
blocks exactly. So how does Java handle a twenty one
bit character if the physical memory bucket is only sixteen
bits wide.
Speaker 2 (15:19):
Well, it employs a patchwork solution called surrogate pairs.
Speaker 1 (15:22):
Surrogate pair.
Speaker 2 (15:23):
Yeah, it takes the twenty one bit character and slices
it into two distinct sixteen bit code units, a high
surrogate and a low serrogu.
Speaker 1 (15:32):
The text uses the example of the mathematical symbol for
the set of Octonians. It's a single character on the screen,
but underneath it spans two sixteen bit memory blocks. Right,
I can see exactly where this breaks are application logic.
If I use the standard dot length method on a
string containing the Octonian symbol, it isn't counting the characters
I see on the screen. Yeah, it's counting the sixteen
bit memory blocks exactly.
Speaker 2 (15:54):
The dot length method will return a value of two.
Speaker 1 (15:56):
And if I try to iterate through that string using
a standard loops so grabbing characters one by one to
parse them, my logic will rip that surrogate pair apart.
Speaker 2 (16:05):
It completely breaks it.
Speaker 1 (16:06):
I'll pull the high surrogate on the first pass, which
is a meaningless piece of data on its own, completely
corrupting the data pipeline.
Speaker 2 (16:14):
If we connect this to the bigger picture, to process
modern texts safely, Java nine forces you to abandon the
concept of characters.
Speaker 1 (16:22):
Okay, so what do we use instead?
Speaker 2 (16:23):
You have to process text using code points. A code
point represents the true valid twenty one bit Unicode value.
Got it, You invoke methods like code point at or
code points which return an in stream. These methods are
designed to recognize surrogate pairs in the underlying array, combine
them back into their valid twenty one bit representation, and
(16:44):
hand them to you safely.
Speaker 1 (16:45):
It acknowledges the reality that human language no longer fits
neatly into sixteen bit architecture. So we've mapped out how
fragile text is inside the heat memory. But the final
layer we need to look at is how we bring
that text into the application form the user. We need
to look at safe input output.
Speaker 2 (17:02):
The front door of your app the interface between the
user's terminal and the system's memory.
Speaker 1 (17:07):
Right, the text highlights the scanner class, which is tied
to system dot N. It's the standard tool for reading
console input. You want the user's name, you call next line.
It feels incredibly intuitive, it does. Yet, if stanner is
so great, why does the author explicitly warn us not
to use it for passwords?
Speaker 2 (17:25):
Well, it introduces two critical vulnerabilities, one at the interface
level and one deep within the JVM's memory management.
Speaker 1 (17:32):
Okay, what's the interface vulnerability.
Speaker 2 (17:34):
It's simple, scanner echoes the keystrokes directly back to the terminal.
Anyone looking at the monitor over your shoulder sees the
password in plain text.
Speaker 1 (17:41):
That's the obvious flaw, right.
Speaker 2 (17:43):
But the deeper vulnerability relates to what scanner actually returns
to your code. Yeah, it returns a string object.
Speaker 1 (17:49):
And we just established that strings and Java are immutable.
Speaker 2 (17:52):
Exactly once you accept that password and store it in
a string variable, it occupies a specific physical location in
the heap. Because it is immutable, you cannot wipe it.
Speaker 1 (18:05):
Wait, really, you can't just delete it.
Speaker 2 (18:07):
No, If you assign a new value to that variable,
you are simply pointing the variable to a different memory address.
The original password remains sitting in the heap as an
orphaned object.
Speaker 1 (18:17):
It's just floating there waiting for the jo garbage collector
to notice it's no longer being used and sweep it away.
Speaker 2 (18:23):
Yeah, but garbage collection in Java is nondeterministic. It doesn't
run instantly. It runs when the heap starts getting full
or when the CPU has idle.
Speaker 1 (18:32):
Cycles, So it could be sitting there for a while.
Speaker 2 (18:35):
Depending on the garbage collection algorithm. Your JVM is running,
an orphan string could sit in memory for milliseconds, or
it could be promoted to an old generation memory space
and sit there for days wow. During that indeterminate window,
if a hacker executes a memory dump of the JVM,
your user's password is sitting right there in plain text.
Speaker 1 (18:55):
You completely lose control over the life cycle of the
sensitive data. So for secure authentication, the text points to
the console class. Instead, you invoke system dot console dot
read password. Aside from suppressing the terminal echo, the architectural
brilliance here is that read password doesn't return a string object.
It returns a primitive char array.
Speaker 2 (19:16):
And a raisin Java are mutable.
Speaker 1 (19:18):
Which means I don't have to wait for the garbage
collector the exact millisecond my authentication logic verifies the password.
I can reach directly into that array's physical memory addresses
and overrate the characters.
Speaker 2 (19:29):
With zeros, you actively sanitize the memory block. You destroy
the cryptographic material before the reference is ever dropped, ensuring
that a subsequent memory dump yields nothing but zeros.
Speaker 1 (19:40):
You are dictating the exact physical state of the hardware exactly.
So what does this all mean synthesizing all of this.
We started out looking to bypass twenty years of legacy
architecture to find the modern, practical parts of Java. Nine.
Speaker 2 (19:54):
Yeah.
Speaker 1 (19:54):
The theme here is that being an effective enterprise developer
isn't about memorizing the deep history of nine teen nineties
object oriented theory.
Speaker 2 (20:02):
No, It's about understanding the boundaries of the machine and
utilizing the modern layer designed to navigate those boundaries.
Speaker 1 (20:10):
It's using jshell to bypass compilation friction and test logic
in an instant. It's invoking big decimal when the CPU's
mantisa limits lie to you. It's utilizing math dot multiply
exec to trap a spilling sign bit before it corrupts
your database. It's parsing strings via code point at because
a sixteen bit array cannot hold a twenty one bit language.
Speaker 2 (20:32):
And it is using primitive arrays for cryptography so you
can manually scrub the heat memory before the garbage collector arrives.
Speaker 1 (20:38):
It requires working with the grain of the modern APIs
while maintaining a strict awareness of the physical limitations governing
the hardware beneath them.
Speaker 2 (20:47):
It's a phenomenal balance of high level abstraction and low
level control.
Speaker 1 (20:50):
It really is. But to close this out, there is
a broader implication. Here we discussed how javas string architecture,
the reliance on surrogate pairs, and the breakdown of basic
length checks exist entirely because the architects in nineteen ninety
one assume sixty five thousand characters would be enough for
all of human history.
Speaker 2 (21:06):
To them, sixteen bits represented an infinite horizon. They couldn't
conceptualize a use case that would exceed.
Speaker 1 (21:13):
It, which forces us to look at what we are
building today as developers construct the foundational architecture for distributed AI,
neural networks and quantum state management. What current infinite limit
are we hard coding into our systems?
Speaker 2 (21:28):
That's the real question.
Speaker 1 (21:29):
What arbitrary data cap or memory structure are we setting
in stone right now that will become a massive structural
trap for engineers twenty years down the line.
Speaker 2 (21:38):
Because the architectures we assume are boundless today will inevitably
become the legacy bottlenecks of tomorrow.
Speaker 1 (21:44):
We are undoubtedly laying our own sixteen bit traps without
even realizing it.
Speaker 2 (21:48):
Very true.
Speaker 1 (21:49):
Thank you for joining us on this deep dive. Keep
questioning the abstractions, look under the hood of your tools,
and we'll see you next time.
If you ask a modern supercomputer today to calculate two
point zero minus one point one, it actually gets the
answer wrong.
Speaker 2 (00:08):
Yeah, it completely fails.
Speaker 1 (00:09):
Right, it won't give you zero point nine, It'll spit
out zero point eight nine, nine nine, just stretching out
until it finally gives up, which is wild, right it is,
And welcome to the deep dive. Today, we're exploring why
the most powerful machines on are still struggle with you know,
grade school arithmetic.
Speaker 2 (00:25):
And more importantly, how we navigate those limits as developers.
Speaker 1 (00:29):
Exactly, So for you the listener, we are taking on
a highly targeted mission.
Speaker 2 (00:33):
Today.
Speaker 1 (00:33):
We are unpacking excerpts from Core Jama Se nine for
the Impatient, second Edition by K. S.
Speaker 2 (00:40):
Horseman, which is such an essential read because I mean,
Java is over two decades old.
Speaker 1 (00:45):
Yeah, it's ancient in tech years, right.
Speaker 2 (00:47):
The ecosystem is just burdened by these layers of legacy architecture.
If you pick up a traditional textbook, you're looking at
thousands of pages dwelling on.
Speaker 1 (00:56):
Ancient history, making you trace the lineage of archaic libe
before you can even write a basic concurrent application.
Speaker 2 (01:04):
Exactly. It's exhausting.
Speaker 1 (01:05):
So our mission today is to cut through all of
that noise. We're extracting the modern practical tools introduced in
Java nine, so you can skip the computer science theory
of the nineteen nineties.
Speaker 2 (01:15):
It's straight to building scalable server side systems.
Speaker 1 (01:19):
But you know, to appreciate the modern workarounds Java nine
gives us, we first have to establish why we're still
building on top of this twenty year old foundation at all.
Speaker 2 (01:28):
Right, because in the fast paced tech world, twenty years
is basically the Mesozoic era.
Speaker 1 (01:34):
Seriously, yet Java is still everywhere. Why is that?
Speaker 2 (01:37):
Well, the survival of the language really comes down to
its initial architectural promise, which is the Java Virtual Machine
the JVM.
Speaker 1 (01:44):
Okay, let's unpack this.
Speaker 2 (01:45):
Prior to this paradigm, if a developer wrote a program,
that code had to be compiled specifically for the underlying hardware.
Speaker 1 (01:52):
Architecture, like physically tied to the machine.
Speaker 2 (01:55):
Yes, you needed a distinct compilation for a Windows environment,
another for a Mac and yet another for a Linux server.
Speaker 1 (02:02):
Which sounds like a nightmare it.
Speaker 2 (02:04):
Was, But Java decoupled the software from the physical hardware.
You compile your source code once into an intermediate state
called bytecode.
Speaker 1 (02:13):
A universal instruction set basically exactly which.
Speaker 2 (02:16):
The JVM then takes over. As long as the device
has a JVM installed, it can interpret that bytecode on.
Speaker 1 (02:22):
The fly, so it translates the intermediate instructions into the
specific machine code of the host device.
Speaker 2 (02:28):
Right, whether that's a high frequency trading server or I
don't know, a smart refrigerator. Oh wow. Yeah, that decoupling
is why massive enterprise back ends and Android ecosystems are
entirely reliant on it today.
Speaker 1 (02:41):
Right, once run anywhere. It was a brilliant design, it
really was. But you know, to achieve that massive enterprise
level scale, Java developed a reputation for being heavily bureaucratic.
It's incredibly verbose.
Speaker 2 (02:53):
Oh. Absolutely.
Speaker 1 (02:53):
To appreciate the first massive shift in Java nine, we
have to look at the classic Hello.
Speaker 2 (02:58):
World program rite a passage.
Speaker 1 (03:00):
Right in almost any other scripting language, if you want
to output a string of text to the console, you
invoke a print command and you're done.
Speaker 2 (03:08):
But traditional Java demands a rigid structural hierarchy before it
will execute a single command.
Speaker 1 (03:14):
Yeah, you have to wrap everything. In an object oriented paradigm,
you declare a public class, allocate a name space inside.
Speaker 2 (03:21):
That class, you declare a public static void main.
Speaker 1 (03:24):
Method cassing it and array of string arguments. Only then
can you call system dot out, dot printle in.
Speaker 2 (03:30):
It's a lot of overhead.
Speaker 1 (03:31):
It's like imagine wanting to fry a single egg for breakfast,
but the environment insists that before you turn on the stove,
you must zone a commercial plot, build a fully permitted
stainless steel kitchen, and pass a municipal health inspection.
Speaker 2 (03:46):
That is Yeah, that's a perfect analogy. It's a phenomenal
structure if you're running a massive restaurant franchise, but it's
deeply punishing if you just want to test a single
line of code. Right, and that uniformity of forcing everything
into a class hierarchy is what makes million line code
bases comprehensible. Sure, but as you pointed out, the friction
for experimentation is incredibly high. So Java nine addresses this
(04:08):
directly by introducing jshell.
Speaker 1 (04:11):
The jshell revolution exactly.
Speaker 2 (04:13):
It's an r epl or reevaluate print loop. You open
a terminal type jshell and you're dropped into a live,
interactive environment.
Speaker 1 (04:20):
Okay, I want to look under the hood here, because
JAMA is a strictly compiled language. Right, You can't just
run raw Java code like it's a Python script. If
I'm sitting in jshall and I just type, you know,
quote hello world, unquote dot length. How is the JVM
executing that without me running a compiler first.
Speaker 2 (04:39):
Well, what's fascinating here is jshell actually leverages the compiler
api introduced in earlier versions of Java. Okay, when you
type that single snippet and hit enter, jshell secretly takes
your fragment of code and wraps it in a synthetic
invisible class.
Speaker 1 (04:54):
Wait really it does that automatically.
Speaker 2 (04:56):
Yep. It runs at synthetic class through the Java compiler
entirely in the system's memory bypassing the hard drive completely.
Speaker 1 (05:02):
Oh wow.
Speaker 2 (05:03):
It manages the class pack dependencies, dynamically loads the resulting
bytecode into the running JVM, executes it, and prints the
result back to your terminal.
Speaker 1 (05:11):
So it is doing all of that boilerplate commercial kitchen
construction invisibly in the background, in milliseconds.
Speaker 2 (05:18):
Exactly, giving you the illusion of an interpreted scripting language.
Speaker 1 (05:22):
That's credible.
Speaker 2 (05:23):
The environment even maps your live session state. If you
declare an integer variable x, jshell keeps that variable alive
in memory for the duration of the seession, allowing you
to manipulate it in subsequent lines.
Speaker 1 (05:36):
That fundamentally alters the development workflow totally.
Speaker 2 (05:39):
Instead of setting up a heavy ide and fighting with
build tools just to see how a specific method behaves,
you test the logic instantly.
Speaker 1 (05:46):
It encourages a sandbox approach, and once you have this
instant feedback loop in jshell, I feel like the very
first thing a developer usually tests is mathematical logic.
Speaker 2 (05:56):
Which brings us back to that supercomputer failing its subtraction.
Speaker 1 (05:59):
Yes, when I ask jshell to calculate two point zero
minus one point one, the output is that trailing string
of nines zero point eight nine nine nine nine. Why
doesn't the language just fix this? Why not make everything
infinitely precise automatically. I mean, we aren't dealing with the
simple software bug here.
Speaker 2 (06:18):
Right, No, not at all. This is a fundamental limitation
of hardware architecture. We are hitting the constraints of the
IE seven five y four standard for floating point arithmetic.
Speaker 1 (06:29):
Okay, break that down for us.
Speaker 2 (06:30):
Well. Human beings calculate in base ten, where fractions like
one tenth have a clean definitive representation, but computers operate
in base two binary logic, mapping data into fixed physical
memory blocks.
Speaker 1 (06:43):
So a standard double precision floating point number in Java
a double is allocated exactly sixty four bits of physical
memory space.
Speaker 2 (06:52):
Yes, the CPU divides those sixty four bits into a
specific structure one bit for the sign, eleven bits for
the exponent, and fifty two bits for the main time
or the significant digits. Got it. When you ask the
CPU to represent the base ten fraction of one tenth
in binary, it becomes a repeating infinite sequence of zeros
and ones.
Speaker 1 (07:09):
Similar to trying to write out one third as a decimal.
You get zero point three three three, and eventually you
just run out of paper and have to stop writing.
Speaker 2 (07:16):
Exactly The sixty four bit memory block is the edge
of the paper. The CPU literally runs out of physical
transistors to hold the infinite binary sequence, so it truncates it.
It chops off the end, which introduces a microscopic roundoff.
Speaker 1 (07:30):
Error, and when the system converts that truncated binary value
back into base ten for your terminal screen, the missing
precision reveals itself as that endless string of nine or feislely. Now,
if you are building a physics engine for a video game,
a microscopic roundoff error doesn't matter.
Speaker 2 (07:46):
No nobody notices.
Speaker 1 (07:47):
But if I'm writing a financial ledger application, I cannot
lose fractions of ascent on every transaction. I need exact precision.
Speaker 2 (07:54):
Right, which is illegal in some context.
Speaker 1 (07:56):
Honestly, I assume this means Java forces developers to choose
between hardware speed and mathematical accuracy.
Speaker 2 (08:02):
That is, the exact tradeoff. Primitive types like double end
float are blazingly fast because they map directly to the
CPU's native instruction set.
Speaker 1 (08:10):
They execute in a single clock cycle.
Speaker 2 (08:12):
Right. But if you require absolute precision for financial math,
the text explicitly warns against primitive types, you must invoke
the big decimal class.
Speaker 1 (08:22):
Which bypasses the CPU's native floating point logic entirely exactly.
Speaker 2 (08:27):
Big decimal is an object. It implements arbitrary precision arithmetic
and software.
Speaker 1 (08:31):
Oh so it handles the math itself.
Speaker 2 (08:33):
Yeah, It dynamically allocates as much heat memory as necessary
to store the exact decimal representation of the number it
guarantees zero point nine.
Speaker 1 (08:42):
But the cost is performance because every mathematical operation requires
object instantiation, method dispatch, and eventual garbage collection.
Speaker 2 (08:51):
Yes, it's an active architectural choice the developer has to make.
Speaker 1 (08:54):
And this hardware limitation applies to whole numbers as well.
Speaker 2 (08:57):
Right, oh, absolutely.
Speaker 1 (08:58):
The text highlights a terrified trap with standard integers. If
you take a standard integer variable and assign up the
value of one billion, and then multiply it by three,
you don't get three billion.
Speaker 2 (09:08):
No, you don't.
Speaker 1 (09:09):
Java quietly outputs negative one billion, two hundred and ninety
four million, nine hundred and sixty seven thousan two hundred
and ninety six. The logic just violently inverts.
Speaker 2 (09:18):
It's crazy. So a standard in in Java is allocated
thirty two bits of memory space and a two's complement
binary representation, which is how modern processors handle signed integers.
The maximum positive value you can fit into those thirty
two bits is just over two billion.
Speaker 1 (09:33):
Because the leftmost bit, the thirty second bit, is reserved
as the sign bit.
Speaker 2 (09:37):
Right. If it's a zero, the number is positive. If
it's a one, the CPU interprets the entire sequence as
a negative number.
Speaker 1 (09:45):
So when you multiply one billion by three, the resulting
binary sequence is too large for the thirty one bits
allocated for the magnitude exactly.
Speaker 2 (09:53):
The binary logic overflows, spilling a one into that thirty
second sign big position. Ah. I see the CPU you
blindly follows its architecture. It sees a one in the
sign position and interprets the resulting garbled sequence as a
massive negative number.
Speaker 1 (10:08):
What makes this uniquely dangerous and traditional Java is that
the multiplication operator the standard asterisk, does this silently.
Speaker 2 (10:15):
That's the worst part. It doesn't warn you.
Speaker 1 (10:17):
The binary spills over the sign flips, and your e
commerce application suddenly thinks a customer ordering three billion dollars
worth of inventory actually has a negative balance.
Speaker 2 (10:26):
Effectively owning the money. It is a silent data corruption.
Speaker 1 (10:30):
So what's the modern Java solution for this? Well?
Speaker 2 (10:32):
Java nine offers a targeted solution in the math library.
Instead of relying on the native multiplication operator, you invoke
math dot multiplay exact.
Speaker 1 (10:41):
Oh okay. Does it allocate more memory to hold the
larger number.
Speaker 2 (10:45):
No, it retains the thirty two bit limitation, but it
actively monitors the operation. Math dot multiply exact bridges the
high level language and the low level CPU logic a soo.
It either checks the hardware's internal overflow flag or simulates
the boundary check. If the calculation exceeds the physical memory limit,
it intercepts the operation and throws an arithmetic.
Speaker 1 (11:07):
Exception, so it crashes the program on purpose. Exactly, it
forces a loud failure rather than permitting a silent corruption,
which is much safer. So primitive math is strictly bound
by the physical architecture of the CPU registers. But if
you think numbers are fragile in memory, the way Java
handles human language is a completely different level of complexity.
Speaker 2 (11:27):
Oh, mathematical logic is universal human language, and the character
encodings required to render it are cultural artifacts mapped onto
physical memory.
Speaker 1 (11:35):
That's a great way to put it. The text introduces
the string class and drops a massive warning right away
regarding conditional logic. It says never use the double equals
operator to compare two strings.
Speaker 2 (11:48):
It causes bugs that can take days to track down
because occasionally using double equals actually works.
Speaker 1 (11:56):
Which creates a false sense of security. Exactly, pack the
pointer mechanics here, because this is where the logic breaks
down for developers coming from languages like Python. The double
equals operator in Java doesn't care about the text itself.
It is evaluating the hexadecimal memory address.
Speaker 2 (12:13):
It's asking do these two variables point to the exact
same physical location in the heap.
Speaker 1 (12:18):
Whereas the dot equals method forces the JVM to travel
to those memory addresses and iterate through the underlying character arrays,
comparing them bite by bite to see if the contents match.
Speaker 2 (12:29):
Right, But you mentioned it sometimes works. Yeah.
Speaker 1 (12:31):
If I define a string ex's hello and why is
hello and use double equals, Java might actually return true.
Why would it do that if there are separate variables?
Speaker 2 (12:39):
So the JVM implements a memory optimization technique called string
in turning. Okay, Because strings are immutable in Java, meaning
they cannot be changed what's created, The JVM maintains a
string pool in the.
Speaker 1 (12:52):
Heap, a pool of existing strings.
Speaker 2 (12:54):
Right, if you declare a string literal hello, the JVM
checks the pool. If Hello already exists. It doesn't allocate
new memory. It simply points your new variable to the
existing memory address.
Speaker 1 (13:08):
So, in that specific scenario, double equals returns true because
both variables point to the identical address exactly.
Speaker 2 (13:14):
But the second you manipulate the text, say you extract
a substring or dynamically a panda character, the JVM is
forced to allocate a completely new memory address for the result, and.
Speaker 1 (13:24):
At that point double equals returns false, even if the
resulting text looks identical on the screen.
Speaker 2 (13:29):
Yep, it's comparing two different hecks addresses. You are bypassing
the intern pool. If you don't understand the pointer mechanics,
the behavior appears entirely erratic.
Speaker 1 (13:38):
Here's where it gets really interesting. The illusion of text
goes even deeper when we examine the chart type.
Speaker 2 (13:43):
Oh, this is fascinating.
Speaker 1 (13:44):
This forces us to look at the historical context of
Java's architecture. Java was designed in nineteen ninety one, during
a period of complete chaos in character encoding.
Speaker 2 (13:54):
Total chaos. You had to ask you for English, which
used seven bits, but Western European languages used different and
eight bit extensions. Russian had KOI eight Japanese had shift jis.
Speaker 1 (14:04):
None of them were compatible.
Speaker 2 (14:06):
No, a text file created in Tokyo looked like pure
gibberish on a terminal in London.
Speaker 1 (14:11):
So the industry solution was the Unicode standard, and in
nineteen ninety one the architects of Unicode decided that a
sixteen bit standard would be sufficient.
Speaker 2 (14:19):
Right, sixteen bits gives you exactly sixty five, five hundred
and thirty six available character slots.
Speaker 1 (14:24):
At the time that seemed infinitely large. They assumed it
could comfortably hold every alphabet and symbol.
Speaker 2 (14:29):
On Earth, and Java was built from the ground up
to natively support this new sixteen bit Unicode standard. The
foundational char primitive type in Java was permanently defined as
a sixteen bit block of.
Speaker 1 (14:40):
Memory, which became a catastrophic legacy trap because sixty five
thousand slots was nowhere.
Speaker 2 (14:45):
Near enough, not even close. By the time they incorporated
comprehensive Chinese ideographs, obscure historical scripts, and complex mathematical formatting,
the Unicode Consortium blew right past the sixty five thousand
limit they ran. Yeah, they were forced to expand Unicode
to a twenty one bit standard, which supports over a
(15:05):
million characters.
Speaker 1 (15:06):
But Java's architecture was already set in stone. A Java
string is essentially an array of these sixteen bit char
blocks exactly. So how does Java handle a twenty one
bit character if the physical memory bucket is only sixteen
bits wide.
Speaker 2 (15:19):
Well, it employs a patchwork solution called surrogate pairs.
Speaker 1 (15:22):
Surrogate pair.
Speaker 2 (15:23):
Yeah, it takes the twenty one bit character and slices
it into two distinct sixteen bit code units, a high
surrogate and a low serrogu.
Speaker 1 (15:32):
The text uses the example of the mathematical symbol for
the set of Octonians. It's a single character on the screen,
but underneath it spans two sixteen bit memory blocks. Right,
I can see exactly where this breaks are application logic.
If I use the standard dot length method on a
string containing the Octonian symbol, it isn't counting the characters
I see on the screen. Yeah, it's counting the sixteen
bit memory blocks exactly.
Speaker 2 (15:54):
The dot length method will return a value of two.
Speaker 1 (15:56):
And if I try to iterate through that string using
a standard loops so grabbing characters one by one to
parse them, my logic will rip that surrogate pair apart.
Speaker 2 (16:05):
It completely breaks it.
Speaker 1 (16:06):
I'll pull the high surrogate on the first pass, which
is a meaningless piece of data on its own, completely
corrupting the data pipeline.
Speaker 2 (16:14):
If we connect this to the bigger picture, to process
modern texts safely, Java nine forces you to abandon the
concept of characters.
Speaker 1 (16:22):
Okay, so what do we use instead?
Speaker 2 (16:23):
You have to process text using code points. A code
point represents the true valid twenty one bit Unicode value.
Got it, You invoke methods like code point at or
code points which return an in stream. These methods are
designed to recognize surrogate pairs in the underlying array, combine
them back into their valid twenty one bit representation, and
(16:44):
hand them to you safely.
Speaker 1 (16:45):
It acknowledges the reality that human language no longer fits
neatly into sixteen bit architecture. So we've mapped out how
fragile text is inside the heat memory. But the final
layer we need to look at is how we bring
that text into the application form the user. We need
to look at safe input output.
Speaker 2 (17:02):
The front door of your app the interface between the
user's terminal and the system's memory.
Speaker 1 (17:07):
Right, the text highlights the scanner class, which is tied
to system dot N. It's the standard tool for reading
console input. You want the user's name, you call next line.
It feels incredibly intuitive, it does. Yet, if stanner is
so great, why does the author explicitly warn us not
to use it for passwords?
Speaker 2 (17:25):
Well, it introduces two critical vulnerabilities, one at the interface
level and one deep within the JVM's memory management.
Speaker 1 (17:32):
Okay, what's the interface vulnerability.
Speaker 2 (17:34):
It's simple, scanner echoes the keystrokes directly back to the terminal.
Anyone looking at the monitor over your shoulder sees the
password in plain text.
Speaker 1 (17:41):
That's the obvious flaw, right.
Speaker 2 (17:43):
But the deeper vulnerability relates to what scanner actually returns
to your code. Yeah, it returns a string object.
Speaker 1 (17:49):
And we just established that strings and Java are immutable.
Speaker 2 (17:52):
Exactly once you accept that password and store it in
a string variable, it occupies a specific physical location in
the heap. Because it is immutable, you cannot wipe it.
Speaker 1 (18:05):
Wait, really, you can't just delete it.
Speaker 2 (18:07):
No, If you assign a new value to that variable,
you are simply pointing the variable to a different memory address.
The original password remains sitting in the heap as an
orphaned object.
Speaker 1 (18:17):
It's just floating there waiting for the jo garbage collector
to notice it's no longer being used and sweep it away.
Speaker 2 (18:23):
Yeah, but garbage collection in Java is nondeterministic. It doesn't
run instantly. It runs when the heap starts getting full
or when the CPU has idle.
Speaker 1 (18:32):
Cycles, So it could be sitting there for a while.
Speaker 2 (18:35):
Depending on the garbage collection algorithm. Your JVM is running,
an orphan string could sit in memory for milliseconds, or
it could be promoted to an old generation memory space
and sit there for days wow. During that indeterminate window,
if a hacker executes a memory dump of the JVM,
your user's password is sitting right there in plain text.
Speaker 1 (18:55):
You completely lose control over the life cycle of the
sensitive data. So for secure authentication, the text points to
the console class. Instead, you invoke system dot console dot
read password. Aside from suppressing the terminal echo, the architectural
brilliance here is that read password doesn't return a string object.
It returns a primitive char array.
Speaker 2 (19:16):
And a raisin Java are mutable.
Speaker 1 (19:18):
Which means I don't have to wait for the garbage
collector the exact millisecond my authentication logic verifies the password.
I can reach directly into that array's physical memory addresses
and overrate the characters.
Speaker 2 (19:29):
With zeros, you actively sanitize the memory block. You destroy
the cryptographic material before the reference is ever dropped, ensuring
that a subsequent memory dump yields nothing but zeros.
Speaker 1 (19:40):
You are dictating the exact physical state of the hardware exactly.
So what does this all mean synthesizing all of this.
We started out looking to bypass twenty years of legacy
architecture to find the modern, practical parts of Java. Nine.
Speaker 2 (19:54):
Yeah.
Speaker 1 (19:54):
The theme here is that being an effective enterprise developer
isn't about memorizing the deep history of nine teen nineties
object oriented theory.
Speaker 2 (20:02):
No, It's about understanding the boundaries of the machine and
utilizing the modern layer designed to navigate those boundaries.
Speaker 1 (20:10):
It's using jshell to bypass compilation friction and test logic
in an instant. It's invoking big decimal when the CPU's
mantisa limits lie to you. It's utilizing math dot multiply
exec to trap a spilling sign bit before it corrupts
your database. It's parsing strings via code point at because
a sixteen bit array cannot hold a twenty one bit language.
Speaker 2 (20:32):
And it is using primitive arrays for cryptography so you
can manually scrub the heat memory before the garbage collector arrives.
Speaker 1 (20:38):
It requires working with the grain of the modern APIs
while maintaining a strict awareness of the physical limitations governing
the hardware beneath them.
Speaker 2 (20:47):
It's a phenomenal balance of high level abstraction and low
level control.
Speaker 1 (20:50):
It really is. But to close this out, there is
a broader implication. Here we discussed how javas string architecture,
the reliance on surrogate pairs, and the breakdown of basic
length checks exist entirely because the architects in nineteen ninety
one assume sixty five thousand characters would be enough for
all of human history.
Speaker 2 (21:06):
To them, sixteen bits represented an infinite horizon. They couldn't
conceptualize a use case that would exceed.
Speaker 1 (21:13):
It, which forces us to look at what we are
building today as developers construct the foundational architecture for distributed AI,
neural networks and quantum state management. What current infinite limit
are we hard coding into our systems?
Speaker 2 (21:28):
That's the real question.
Speaker 1 (21:29):
What arbitrary data cap or memory structure are we setting
in stone right now that will become a massive structural
trap for engineers twenty years down the line.
Speaker 2 (21:38):
Because the architectures we assume are boundless today will inevitably
become the legacy bottlenecks of tomorrow.
Speaker 1 (21:44):
We are undoubtedly laying our own sixteen bit traps without
even realizing it.
Speaker 2 (21:48):
Very true.
Speaker 1 (21:49):
Thank you for joining us on this deep dive. Keep
questioning the abstractions, look under the hood of your tools,
and we'll see you next time.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Hey Jonas!
Hey Jonas! The official Jonas Brothers podcast. Hosted by Kevin, Joe, and Nick Jonas. It’s the Jonas Brothers you know... musicians, actors, and well, yes, brothers. Now, they’re sharing another side of themselves in the playful, intimate, and irreverent way only they can. Spend time with the Jonas Brothers here and stay a little bit longer for deep conversations like never before.
Betrayal Weekly
Betrayal Weekly is back for a new season. Every Thursday, Betrayal Weekly shares first-hand accounts of broken trust, shocking deceptions, and the trail of destruction they leave behind. Hosted by Andrea Gunning, this weekly ongoing series digs into real-life stories of betrayal and the aftermath. From stories of double lives to dark discoveries, these are cautionary tales and accounts of resilience against all odds. From the producers of the critically acclaimed Betrayal series, Betrayal Weekly drops new episodes every Thursday. If you would like to share your story, you can reach out to the Betrayal Team by emailing them at betrayalpod@gmail.com and follow us on Instagram at @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.