Ever wondered how the JVM debugger 'Evaluate' feature works in IDEs? Long ago I thought that the Java debug interface (JDI) actually allows you to specify the expression and get back its value.

However, this is not quite possible: there's no Java language compiler inside the JVM. When the process is paused JDI allows you to read or write any variables and fields or even execute an existing method with given arguments. But nothing like addition or multiplication.
On the other hand, #IntelliJIDEA debugger allows you to evaluate even statements! You can write there `for`, `if`, `while`, `switch` - whatever. You can even declare local variables. So how this works?
The answer is simple: IDEA debugger has a built-in interpreter for Java! If you access an existing variable or a field, call a method or instantiate an object, it queries JDI. Otherwise, IDE itself does all the calculations.
The amusing thing is that debugger authors didn't bother to make it as strict as Java itself, so the language inside the interpreter is a much more permissive version of Java. For example, you don't need to initialize variables there! Default values like 0 are used automatically.
Of course, final variables could be changed. Why artificial limitations?
Another thing: most of the casts are not necessary. This interpreted Java more resembles dynamically typed languages like JavaScript. Duck-typing works: if there's a method, we can call it. Even if the highlighter complains.
Switch statements and expressions are more permissive there: you can switch over any type. Also, no default is necessary for switch expressions. If it's not visited, the evaluation will be successful.
In addition to use any type, you can use any expressions as case labels, not just constants! The first matching branch will be executed.
Finally, even if your project still uses Java 6 JDK, it doesn't stop you from using new language features. For example, 'var' declarations and patterns in instanceof work perfectly, because they are interpreted by IDE, not by your JDK. Just ignore error messages!

More from Tech

"I really want to break into Product Management"

make products.

"If only someone would tell me how I can get a startup to notice me."

Make Products.

"I guess it's impossible and I'll never break into the industry."

MAKE PRODUCTS.

Courtesy of @edbrisson's wonderful thread on breaking into comics –
https://t.co/TgNblNSCBj – here is why the same applies to Product Management, too.


There is no better way of learning the craft of product, or proving your potential to employers, than just doing it.

You do not need anybody's permission. We don't have diplomas, nor doctorates. We can barely agree on a single standard of what a Product Manager is supposed to do.

But – there is at least one blindingly obvious industry consensus – a Product Manager makes Products.

And they don't need to be kept at the exact right temperature, given endless resource, or carefully protected in order to do this.

They find their own way.
A brief analysis and comparison of the CSS for Twitter's PWA vs Twitter's legacy desktop website. The difference is dramatic and I'll touch on some reasons why.

Legacy site *downloads* ~630 KB CSS per theme and writing direction.

6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices

https://t.co/qyl4Bt1i5x


PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.

735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices

https://t.co/w7oNG5KUkJ


The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.

The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.

You May Also Like