Default

default

Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 2. Mathematical Description and 2.1. Numerical Algorithms for Nonlinear Equations 2. Mathematical Description and 2.1. Numerical Algorithms for Nonlinear Equations 2.2. Globalization Strategies 2.2. Globalization Strategies 2.3. Sensitivity Analysis 2.3. Sensitivity Analysis 2.4. Matrix Coloring & Sparse Automatic Differentiation 2.4. Matrix Coloring & Sparse Automatic Differentiation 3. Special Capabilities 3. Special Capabilities 3.1. Composable Building Blocks 3.1. Composable Building Blocks 3.2. Smart PolyAlgortihm Defaults 3.2. Smart PolyAlgortihm Defaults 3.3. Non-Allocating Static Algorithms inside GPU Kernels 3.3. Non-Allocating Static Algorithms inside GPU Kernels 3.4. Automatic Sparsity Exploitation 3.4. Automatic Sparsity Exploitation 3.5. Generalized Jacobian-Free Nonlinear Solvers using Krylov Methods 3.5. Generalized Jacobian-Free Nonlinear Solvers using Krylov Methods 4. Results and 4.1. Robustness on 23 Test Problems 4. Results and 4.1. Robustness on 23 Test Problems 4.2. Initializing the Doyle-Fuller-Newman (DFN) Battery Model 4.2. Initializing the Doyle-Fuller-Newman (DFN) Battery Model 4.3. Large Ill-Conditioned Nonlinear Brusselator System 4.3. Large Ill-Conditioned Nonlinear Brusselator System 5. Conclusion and References 5. Conclusion and References 3.2. Smart PolyAlgortihm Defaults NonlinearSolve.jl comes with a set of well-benchmarked defaults designed to be fast and robust in the average case. For Nonlinear Problems with Intervals, we default to Interpolate, Truncate, and Project (ITP) [48]. For more advanced problems, we default to a polyalgorithm that selects the internal solvers based on the problem specification. Our selection happens twofold, first at the nonlinear solver level [Figure 4] and next at the linear solver level[10] [Figure 5]. 3.2.1. Default Nonlinear Solver Selection. By default, we use a polyalgorithm that balances speed and robustness. We start with Quasi-Newton Algorithms – Broyden [49] and Klement [50]. If these fail, we use a modified version of Broyden, 3.2.1. Default Nonlinear Solver Selection. using a true Jacobian initialization. Finally, if Quasi-Newton Methods fail, we use . Newton Raphson with Line Search and finally fall back to Trust Region Methods. Additionally, if a custom Jacobian function is provided or the system is small (≤ 25 states), we avoid using Quasi-Newton Methods and directly use the first-order solvers. We have designed our default to be robust, allowing it to solve all 23 test problems [Subsection 4.1]. Additionally, as seen in Figure 9, our default solver successfully solves new problems. Our default strongly contrasts with other software like Sundials and MINPACK, which can only solve 15 (22 with line search) and 17 (possibly 18, depending on settings) problems, respectively, out of the 23 problems. 3.2.2. Default Linear Solver Selection. For ill-conditioned Jacobians in the linear system (𝐴𝑥 = 𝑏), we default to QR for regular cases or SVD for extremely ill-conditioned cases. We run a polyalgorithm for well-conditioned systems to determine the best linear solver. If 𝐴 is a matrix-free object, we use GMRES [51] from Krylov.jl [52] and solve the linear system without ever materializing the Jacobian. 3.2.2. Default Linear Solver Selection. For other cases, if 𝐴 is reasonably small, we use the native Julia Implementation . of LU Factorization [53] from RecursiveFactorization.jl [54]. We use the LU factorization routines from OpenBLAS or MKL for larger systems if present on the user’s system. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv [10] Default Linear Solver selection happens in LinearSolve.jl. Authors:
(1) AVIK PAL, CSAIL MIT, Cambridge, MA;
(2) FLEMMING HOLTORF;
(3) AXEL LARSSON;
(4) TORKEL LOMAN;
(5) UTKARSH;
(6) FRANK SCHÄFER;
(7) QINGYU QU;
(8) ALAN EDELMAN;
(9) CHRIS RACKAUCKAS, CSAIL MIT, Cambridge, MA. Authors: Authors: (1) AVIK PAL, CSAIL MIT, Cambridge, MA; (2) FLEMMING HOLTORF; (3) AXEL LARSSON; (4) TORKEL LOMAN; (5) UTKARSH; (6) FRANK SCHÄFER; (7) QINGYU QU; (8) ALAN EDELMAN; (9) CHRIS RACKAUCKAS, CSAIL MIT, Cambridge, MA.

NonlinearSolve.jl: Smart Defaults for Robust and Efficient Nonlinear Solving

The HackerNoon Newsletter: Code Smell 282 - Bad Defaults and How to Fix Them (12/3/2024)

Defaults Can Sink You TL;DR: Treat unknown responses as unauthorized, not as valid. Problems Security risks
Ignoring unknown cases
Error Misinterpretation
Defaulting to valid states
Mismatch Authorizations
Failing to log events
Exploitation Potential Solutions Validate all responses against a closed set of known codes.
Default (and unknown) to unauthorized or Remove Defaults.
Log every mismatched or unexpected case for analysis.
Test with edge scenarios.
Synchronize response pools with processors regularly to avoid outdated codes.
Focus on security making it a shift left process.
Design systems with change resilience to handle evolving scenarios. Context Today is computer security day and every programmer needs to acknowledge its responsibility. Imagine an application handling sales that relies on response pools from credit card processors to handle transactions. Each credit card processor provides predefined response codes for various situations, such as insufficient balance or expired cards. The issue begins when a processor adds a new response code for denied transactions but doesn't notify the platform. The application doesn't recognize the new code, defaults to treating it as "not found," and authorizes the purchase. Users notice this flaw and exploit it to make unauthorized purchases. The platform's revenue plummets, leading to bankruptcy. Sample Code Wrong String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    default:
        // Authorize purchase
        break;
} Right String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "APPROVED":
        // Authorize purchase
        break;
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    case "DECLINED_NEW_REASON":
        // Handle new declined reason
        break;
    default:
        // Reject purchase (default case for unknown responses)
        break;
} Detection [x]Manual You can detect this smell by reviewing error-handling logic. Check if the system logs and denies unrecognized cases. Automated tests can help identify if new or unexpected inputs default to valid actions. Static analysis tools can help by flagging potentially incomplete error handling. Tags Security Level [x]Intermediate Why Bijection Is Important It's critical to maintain a one-to-one correspondence between your application's internal representation of payment processor responses and the actual codes returned by the processor. When you break the Bijection, you create a mismatch. The application interprets unknown codes incorrectly, leading to unexpected behavior, security holes, and potentially disastrous business consequences. AI Generation AI tools can create this smell if you don't specify how to handle unknown cases. For example, generic error handling might default to benign outcomes like "not found" or "success." AI Detection AI generators can fix this smell when you instruct them to treat unknown cases as unauthorized and emphasize logging and testing unexpected scenarios. Try Them! Remember: AI Assistants make lots of mistakes Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini Conclusion Always handle unknown cases cautiously. Defaults like "not found" can lead to severe security issues and financial losses. Make logging and denying unknown responses part of your development practices. Make shift-left decisions related to security while programming. Relations https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352 Disclaimer Code Smells are my opinion. Credits Photo by Nathana Rebouças on Unsplash https://www.youtube.com/watch?v=J2QOejhA6ek Assumptions are the mother of all failures. Said Ouissal Software Engineering Great Quotes This article is part of the CodeSmell Series. How to Find the Stinky Parts of your Code Defaults Can Sink You Defaults Can Sink You TL;DR: Treat unknown responses as unauthorized, not as valid. TL;DR: Treat unknown responses as unauthorized, not as valid. Problems Security risks Ignoring unknown cases Error Misinterpretation Defaulting to valid states Mismatch Authorizations Failing to log events Exploitation Potential Security risks Ignoring unknown cases Error Misinterpretation Defaulting to valid states Mismatch Authorizations Failing to log events Exploitation Potential Solutions Validate all responses against a closed set of known codes. Default (and unknown) to unauthorized or Remove Defaults. Log every mismatched or unexpected case for analysis. Test with edge scenarios. Synchronize response pools with processors regularly to avoid outdated codes. Focus on security making it a shift left process. Design systems with change resilience to handle evolving scenarios. Validate all responses against a closed set of known codes. Default (and unknown) to unauthorized or Remove Defaults . Remove Defaults Log every mismatched or unexpected case for analysis. Test with edge scenarios. Synchronize response pools with processors regularly to avoid outdated codes. Focus on security making it a shift left process. Design systems with change resilience to handle evolving scenarios. Context Today is computer security day and every programmer needs to acknowledge its responsibility. computer security day Imagine an application handling sales that relies on response pools from credit card processors to handle transactions. Each credit card processor provides predefined response codes for various situations, such as insufficient balance or expired cards. The issue begins when a processor adds a new response code for denied transactions but doesn't notify the platform. The application doesn't recognize the new code, defaults to treating it as "not found," and authorizes the purchase. Users notice this flaw and exploit it to make unauthorized purchases. The platform's revenue plummets, leading to bankruptcy. Sample Code Wrong String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    default:
        // Authorize purchase
        break;
} String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    default:
        // Authorize purchase
        break;
} Right String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "APPROVED":
        // Authorize purchase
        break;
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    case "DECLINED_NEW_REASON":
        // Handle new declined reason
        break;
    default:
        // Reject purchase (default case for unknown responses)
        break;
} String response = paymentProcessor.authorize(cardDetails);

switch (response) {
    case "APPROVED":
        // Authorize purchase
        break;
    case "DECLINED_INSUFFICIENT_FUNDS":
        // Handle insufficient funds
        break;
    case "DECLINED_EXPIRED_CARD":
        // Handle expired card
        break;
    case "DECLINED_NEW_REASON":
        // Handle new declined reason
        break;
    default:
        // Reject purchase (default case for unknown responses)
        break;
} Detection [x]Manual [x] Manual [x] You can detect this smell by reviewing error-handling logic. Check if the system logs and denies unrecognized cases. Automated tests can help identify if new or unexpected inputs default to valid actions. Static analysis tools can help by flagging potentially incomplete error handling. Tags Security Security Level [x]Intermediate [x] Intermediate [x] Why Bijection Is Important It's critical to maintain a one-to-one correspondence between your application's internal representation of payment processor responses and the actual codes returned by the processor. When you break the Bijection , you create a mismatch. Bijection The application interprets unknown codes incorrectly, leading to unexpected behavior, security holes, and potentially disastrous business consequences. AI Generation AI tools can create this smell if you don't specify how to handle unknown cases. For example, generic error handling might default to benign outcomes like "not found" or "success." AI Detection AI generators can fix this smell when you instruct them to treat unknown cases as unauthorized and emphasize logging and testing unexpected scenarios. Try Them! Remember: AI Assistants make lots of mistakes Remember: AI Assistants make lots of mistakes Without Proper Instructions

With Specific Instructions



ChatGPT

ChatGPT



Claude

Claude



Perplexity

Perplexity



Copilot

Copilot



Gemini

Gemini Without Proper Instructions

With Specific Instructions ChatGPT

ChatGPT Claude

Claude Perplexity

Perplexity Copilot

Copilot Gemini

Gemini Without Proper Instructions With Specific Instructions Without Proper Instructions Without Proper Instructions With Specific Instructions With Specific Instructions ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT ChatGPT Claude Claude Claude Claude Claude Claude Claude Claude Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Perplexity Copilot Copilot Copilot Copilot Copilot Copilot Copilot Copilot Gemini Gemini Gemini Gemini Gemini Gemini Gemini Gemini Conclusion Always handle unknown cases cautiously. Defaults like "not found" can lead to severe security issues and financial losses. Make logging and denying unknown responses part of your development practices. Make shift-left decisions related to security while programming. Relations https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxii https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352 https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352 Disclaimer Code Smells are my opinion . opinion Credits Photo by Nathana Rebouças on Unsplash Nathana Rebouças Unsplash https://www.youtube.com/watch?v=J2QOejhA6ek https://www.youtube.com/watch?v=J2QOejhA6ek Assumptions are the mother of all failures. Assumptions are the mother of all failures. Said Ouissal Said Ouissal Software Engineering Great Quotes Software Engineering Great Quotes This article is part of the CodeSmell Series. How to Find the Stinky Parts of your Code How to Find the Stinky Parts of your Code

Code Smell 282 - Bad Defaults and How to Fix Them

কোড গন্ধ 282 - খারাপ ডিফল্ট এবং সেগুলি কীভাবে ঠিক করা যায়

Code Smell 282 - Κακές προεπιλογές και πώς να τις διορθώσετε

Código Smell 282: Valores predeterminados incorrectos y cómo solucionarlos

קוד ריח 282 - ברירות מחדל גרועות וכיצד לתקן אותן

Code Smell 282 - Վատ լռելյայն և ինչպես շտկել դրանք

コードスメル 282 - 不適切なデフォルトとその修正方法

Code Smell 282 - Муу анхдагч алдаа ба тэдгээрийг хэрхэн засах вэ

Kod Bau 282 - Lalai Buruk dan Cara Membaikinya

Запах кода 282 — плохие значения по умолчанию и как их исправить

Zápach kódu 282 – Zlé predvolené nastavenia a ako ich opraviť

Code Smell 282 - Dåliga standardvärden och hur man åtgärdar dem

Mùi mã 282 - Mặc định xấu và cách khắc phục

In this post, I'll explain how to provide a default value when querying an absent key in a hash map in different programming languages. Java Let's start with Java, my first professional programming language. In older versions, retrieving a value from a map required using the get() method: Map map = new HashMap();                                 //1
Object value = map.get(new Object());                    //2
if (value == null) {
    value = "default";                                   //3
} Initialize an empty map
Attempt to retrieve a non-existent key
Assign a default value if the key is absent With Java 1.8, the Map interface introduced a more concise way to handle absent keys: var map = new HashMap<Object, String>();
var value = map.getOrDefault(new Object(), "default");   //1 Retrieve the value with a default in one step Kotlin Kotlin provides several approaches to retrieving values from a map: get() and getOrDefault() function just like their Java counterparts.
getValue() throws an exception if the key is missing.
getOrElse() accepts a lambda to provide a default value lazily. val map = mapOf<Any, String>()
val default = map.getOrDefault("absent", "default")      //1
val lazyDefault = map.getOrElse("absent") { "default" }  //2 Retrieve the default value
Lazily evaluate the default value Python Python is less forgiving than Java when handling absent keys—it raises a KeyError: map = {}
value = map['absent']                                    #1 Raises a KeyError To avoid this, Python offers the get() method: map = {}
value = map.get('absent', 'default')                     #1 Alternatively, Python's collections.defaultdict allows setting a default for all absent keys: from collections import defaultdict
map = defaultdict(lambda: 'default')                     #1
value = map['absent'] Automatically provide a default value for any absent key Ruby Ruby's default behavior returns nil for absent keys: map = {}
value = map['absent'] For a default value, use the fetch method: map = {}
value = map.fetch('absent', 'default')                  #1 Provide a default value for the absent key Ruby also supports a more flexible approach with closures: map = {}
value = map.fetch('absent') { |key| key }               #1 Return the queried key instead of a constant Lua My experience with Lua is relatively new, having picked it up for Apache APISIX. Let's start with Lua's map syntax: map = {}                                                --1
map["a"] = "A"
map["b"] = "B"
map["c"] = "C"
for k, v in pairs(map) do                               --2
  print(k, v)                                           --3
end Initialize a new map
Iterate over key-value pairs
Print each key-value pair Fun fact: the syntax for tables is the same as for maps: table = {}                                              --1
table[0] = "zero"
table[1] = "one"
table[2] = "two"
for k,v in ipairs(table) do                             --2
  print(k, v)                                           --3
end Initialize a new map


Loop over the pairs of key values


Print the following:
1	one
2	two

Lua arrays start at index 0! We can mix and match indices and keys. The syntax is similar, but there's no difference between a table and a map. Indeed, Lua calls the data structure a table: something = {}                                              
something["a"] = "A"
something[1] = "one"
something["b"] = "B"
for k,v in pairs(something) do
  print(k, v)
end The result is the following: 1	one
a	A
b	B I n Lua, absent keys return nil by default: map = {}
value = map['absent'] To provide a default, Lua uses metatables and the __index metamethod: Metatables allow us to change the behavior of a table. For instance, using metatables, we can define how Lua computes the expression a+b, where a and b are tables. Whenever Lua tries to add two tables, it checks whether either of them has a metatable and whether that metatable has an __add field. If Lua finds this field, it calls the corresponding value (the so-called metamethod, which should be a function) to compute the sum.
-- Metatables and Metamethods Each table in Lua may have its own metatable. As I said earlier, when we access an absent field in a table, the result is nil. This is true, but it is not the whole truth. Such access triggers the interpreter to look for an __index metamethod: if there is no such method, as usually happens, then the access results in nil; otherwise, the metamethod will provide the result.
-- The __index Metamethod Here's how to use it: table = {}                                              --1
mt = {}                                                 --2
setmetatable(table, mt)                                 --3
mt.__index = function (table, key)                      --4
  return key
end
default = table['absent']                               --5 Create the table
Create a metatable
Associate the metatable with the table
Define the __index function to return the absent key
The __index function is called because the key is absent Summary This post explored how to provide default values when querying absent keys across various programming languages. Here's a quick summary: Scope

Scope

Value

Value



Programming Language

Per call

Per map

Static

Lazy



Java

❎

❌

❎

❌



Kotlin

❎

❌

❎

❎



Python

❎

❎

❌

❎



Ruby

❎

❌

❎

❎



Lua

❌

❎

❎

❌ In this post, I'll explain how to provide a default value when querying an absent key in a hash map in different programming languages. Java Let's start with Java, my first professional programming language. In older versions, retrieving a value from a map required using the get() method: get() Map map = new HashMap();                                 //1
Object value = map.get(new Object());                    //2
if (value == null) {
    value = "default";                                   //3
} Map map = new HashMap();                                 //1
Object value = map.get(new Object());                    //2
if (value == null) {
    value = "default";                                   //3
} Initialize an empty map Attempt to retrieve a non-existent key Assign a default value if the key is absent Initialize an empty map Attempt to retrieve a non-existent key Assign a default value if the key is absent With Java 1.8, the Map interface introduced a more concise way to handle absent keys: Map var map = new HashMap<Object, String>();
var value = map.getOrDefault(new Object(), "default");   //1 var map = new HashMap<Object, String>();
var value = map.getOrDefault(new Object(), "default");   //1 Retrieve the value with a default in one step Retrieve the value with a default in one step Kotlin Kotlin provides several approaches to retrieving values from a map: get() and getOrDefault() function just like their Java counterparts. getValue() throws an exception if the key is missing. getOrElse() accepts a lambda to provide a default value lazily. get() and getOrDefault() function just like their Java counterparts. get() getOrDefault() getValue() throws an exception if the key is missing. getValue() getOrElse() accepts a lambda to provide a default value lazily. getOrElse() val map = mapOf<Any, String>()
val default = map.getOrDefault("absent", "default")      //1
val lazyDefault = map.getOrElse("absent") { "default" }  //2 val map = mapOf<Any, String>()
val default = map.getOrDefault("absent", "default")      //1
val lazyDefault = map.getOrElse("absent") { "default" }  //2 Retrieve the default value Lazily evaluate the default value Retrieve the default value Lazily evaluate the default value Python Python is less forgiving than Java when handling absent keys—it raises a KeyError : KeyError map = {}
value = map['absent']                                    #1 map = {}
value = map['absent']                                    #1 Raises a KeyError Raises a KeyError KeyError To avoid this, Python offers the get() method: get() map = {}
value = map.get('absent', 'default')                     #1 map = {}
value = map.get('absent', 'default')                     #1 Alternatively, Python's collections.defaultdict allows setting a default for all absent keys: collections.defaultdict from collections import defaultdict
map = defaultdict(lambda: 'default')                     #1
value = map['absent'] from collections import defaultdict
map = defaultdict(lambda: 'default')                     #1
value = map['absent'] Automatically provide a default value for any absent key Automatically provide a default value for any absent key Ruby Ruby's default behavior returns nil for absent keys: nil map = {}
value = map['absent'] map = {}
value = map['absent'] For a default value, use the fetch method: fetch map = {}
value = map.fetch('absent', 'default')                  #1 map = {}
value = map.fetch('absent', 'default')                  #1 Provide a default value for the absent key Provide a default value for the absent key Ruby also supports a more flexible approach with closures: map = {}
value = map.fetch('absent') { |key| key }               #1 map = {}
value = map.fetch('absent') { |key| key }               #1 Return the queried key instead of a constant Return the queried key instead of a constant Lua My experience with Lua is relatively new, having picked it up for Apache APISIX. Let's start with Lua's map syntax: map = {}                                                --1
map["a"] = "A"
map["b"] = "B"
map["c"] = "C"
for k, v in pairs(map) do                               --2
  print(k, v)                                           --3
end map = {}                                                --1
map["a"] = "A"
map["b"] = "B"
map["c"] = "C"
for k, v in pairs(map) do                               --2
  print(k, v)                                           --3
end Initialize a new map Iterate over key-value pairs Print each key-value pair Initialize a new map Iterate over key-value pairs Print each key-value pair Fun fact: the syntax for tables is the same as for maps: table = {}                                              --1
table[0] = "zero"
table[1] = "one"
table[2] = "two"
for k,v in ipairs(table) do                             --2
  print(k, v)                                           --3
end table = {}                                              --1
table[0] = "zero"
table[1] = "one"
table[2] = "two"
for k,v in ipairs(table) do                             --2
  print(k, v)                                           --3
end Initialize a new map Loop over the pairs of key values Print the following:
1	one
2	two

Lua arrays start at index 0! Initialize a new map Initialize a new map Loop over the pairs of key values Loop over the pairs of key values Print the following: 1	one
2	two Lua arrays start at index 0! Print the following: 1	one
2	two 1	one
2	two Lua arrays start at index 0! We can mix and match indices and keys. The syntax is similar, but there's no difference between a table and a map. Indeed, Lua calls the data structure a table: something = {}                                              
something["a"] = "A"
something[1] = "one"
something["b"] = "B"
for k,v in pairs(something) do
  print(k, v)
end something = {}                                              
something["a"] = "A"
something[1] = "one"
something["b"] = "B"
for k,v in pairs(something) do
  print(k, v)
end The result is the following: 1	one
a	A
b	B 1	one
a	A
b	B I n Lua, absent keys return nil by default: nil map = {}
value = map['absent'] map = {}
value = map['absent'] To provide a default, Lua uses metatables and the __index metamethod: __index Metatables allow us to change the behavior of a table. For instance, using metatables, we can define how Lua computes the expression a+b, where a and b are tables. Whenever Lua tries to add two tables, it checks whether either of them has a metatable and whether that metatable has an __add field. If Lua finds this field, it calls the corresponding value (the so-called metamethod, which should be a function) to compute the sum. -- Metatables and Metamethods Metatables allow us to change the behavior of a table. For instance, using metatables, we can define how Lua computes the expression a+b , where a and b are tables. Whenever Lua tries to add two tables, it checks whether either of them has a metatable and whether that metatable has an __add field. If Lua finds this field, it calls the corresponding value (the so-called metamethod , which should be a function) to compute the sum. a+b a b __add metamethod -- Metatables and Metamethods Metatables and Metamethods Each table in Lua may have its own metatable . metatable As I said earlier, when we access an absent field in a table, the result is nil. This is true, but it is not the whole truth. Such access triggers the interpreter to look for an __index metamethod: if there is no such method, as usually happens, then the access results in nil; otherwise, the metamethod will provide the result. -- The __index Metamethod As I said earlier, when we access an absent field in a table, the result is nil . This is true, but it is not the whole truth. Such access triggers the interpreter to look for an __index metamethod: if there is no such method, as usually happens, then the access results in nil ; otherwise, the metamethod will provide the result. nil __index nil -- The __index Metamethod The __index Here's how to use it: table = {}                                              --1
mt = {}                                                 --2
setmetatable(table, mt)                                 --3
mt.__index = function (table, key)                      --4
  return key
end
default = table['absent']                               --5 table = {}                                              --1
mt = {}                                                 --2
setmetatable(table, mt)                                 --3
mt.__index = function (table, key)                      --4
  return key
end
default = table['absent']                               --5 Create the table Create a metatable Associate the metatable with the table Define the __index function to return the absent key The __index function is called because the key is absent Create the table Create a metatable Associate the metatable with the table Define the __index function to return the absent key __index The __index function is called because the key is absent __index Summary This post explored how to provide default values when querying absent keys across various programming languages. Here's a quick summary: Scope

Scope

Value

Value



Programming Language

Per call

Per map

Static

Lazy



Java

❎

❌

❎

❌



Kotlin

❎

❌

❎

❎



Python

❎

❎

❌

❎



Ruby

❎

❌

❎

❎



Lua

❌

❎

❎

❌ Scope

Scope

Value

Value Programming Language

Per call

Per map

Static

Lazy Java

❎

❌

❎

❌ Kotlin

❎

❌

❎

❎ Python

❎

❎

❌

❎ Ruby

❎

❌

❎

❎ Lua

❌

❎

❎

❌ Scope Scope Value Value Scope Scope Scope Scope Value Value Value Value Programming Language Per call Per map Static Lazy Programming Language Programming Language Per call Per call Per map Per map Static Static Lazy Lazy Java ❎ ❌ ❎ ❌ Java Java ❎ ❎ ❌ ❌ ❎ ❎ ❌ ❌ Kotlin ❎ ❌ ❎ ❎ Kotlin Kotlin ❎ ❎ ❌ ❌ ❎ ❎ ❎ ❎ Python ❎ ❎ ❌ ❎ Python Python ❎ ❎ ❎ ❎ ❌ ❌ ❎ ❎ Ruby ❎ ❌ ❎ ❎ Ruby Ruby ❎ ❎ ❌ ❌ ❎ ❎ ❎ ❎ Lua ❌ ❎ ❎ ❌ Lua Lua ❌ ❌ ❎ ❎ ❎ ❎ ❌ ❌

Default Values for Absent Keys: A Cross-Language Guide to Hash Map Querying

United States of America v. Google LLC., Court Filing, retrieved on April 30, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 25 of 37. C. The Foreclosure Created By Google’s Agreements Is Enhanced By Google’s Ownership Of The Chrome Browser 968. About 20% of all general search queries in the United States go through the default on user-downloaded versions of Chrome (e.g., Chrome on Windows and Apple devices). Tr. 5763:9–13, 5765:6–15 (Whinston (Pls. Expert)) (user-downloaded Chrome includes Chrome on Windows and Apple devices; explaining that the yellow part of the bar (20%) on UPXD104 at 37 is user-downloaded Chrome); id. 10639:10–17 (20% of U.S. search queries come through user-downloaded Chrome). These are defaults not challenged by Plaintiffs’ complaint but still affect the portion of the relevant markets available to rivals and thus magnify the significance of the foreclosure created by the challenged agreements. 969. Because Google always sets itself as the Chrome search default, rivals cannot achieve distribution by being set as that default. In other words, queries going through the default on user-downloaded Chrome are not “fully available” to Google’s rivals. Tr. 922:19–23 (Kolotouros (Google)) (“Chrome, as an application, has Google as the default search engine, that is correct.”); Tr. 5768:2–18 (Whinston (Pls. Expert)) (User-downloaded “Chrome queries are not fully available . . . to rivals, because Chrome is coming with a default in it to Google.”); id. 10639:10–19 (Google sets itself as the default on Chrome, which means rivals cannot access default distribution through Chrome.). 970. Even if Google is not engaging in exclusionary conduct by setting itself as the default on Chrome, the presence of Chrome makes the foreclosure caused by Google’s exclusionary contracts more significant. Tr. 5768:2–18 (Whinston (Pls. Expert)) (explaining that the presence of Chrome “color[s]” what the foreclosure range means—“when you think about these numbers [the 33% and the 50%,] . . . you shouldn’t think of it . . . relative to a hundred percent. You really should think of it in some sense relative to some smaller possible available market because of the presence of Chrome.”); id. 5752:18–5753:9 (discussing UPXD104 at 33, which states that foreclosure analysis needs to “consider[] how much of the market is available to rival sellers.”). Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.
This court case retrieved on April 30, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. United States of America v. Google LLC., Court Filing, retrieved on April 30, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 25 of 37. United States of America v. Google LLC., Court Filing, retrieved on April 30, 2024, is part of HackerNoon’s Legal PDF Series . You can jump to any part of this filing here . This part is 25 of 37. HackerNoon’s Legal PDF Series here C. The Foreclosure Created By Google’s Agreements Is Enhanced By Google’s Ownership Of The Chrome Browser 968. About 20% of all general search queries in the United States go through the default on user-downloaded versions of Chrome (e.g., Chrome on Windows and Apple devices). Tr. 5763:9–13, 5765:6–15 (Whinston (Pls. Expert)) (user-downloaded Chrome includes Chrome on Windows and Apple devices; explaining that the yellow part of the bar (20%) on UPXD104 at 37 is user-downloaded Chrome); id. 10639:10–17 (20% of U.S. search queries come through user-downloaded Chrome). These are defaults not challenged by Plaintiffs’ complaint but still affect the portion of the relevant markets available to rivals and thus magnify the significance of the foreclosure created by the challenged agreements. 969. Because Google always sets itself as the Chrome search default, rivals cannot achieve distribution by being set as that default. In other words, queries going through the default on user-downloaded Chrome are not “fully available” to Google’s rivals. Tr. 922:19–23 (Kolotouros (Google)) (“Chrome, as an application, has Google as the default search engine, that is correct.”); Tr. 5768:2–18 (Whinston (Pls. Expert)) (User-downloaded “Chrome queries are not fully available . . . to rivals, because Chrome is coming with a default in it to Google.”); id. 10639:10–19 (Google sets itself as the default on Chrome, which means rivals cannot access default distribution through Chrome.). 970. Even if Google is not engaging in exclusionary conduct by setting itself as the default on Chrome, the presence of Chrome makes the foreclosure caused by Google’s exclusionary contracts more significant. Tr. 5768:2–18 (Whinston (Pls. Expert)) (explaining that the presence of Chrome “color[s]” what the foreclosure range means—“when you think about these numbers [the 33% and the 50%,] . . . you shouldn’t think of it . . . relative to a hundred percent. You really should think of it in some sense relative to some smaller possible available market because of the presence of Chrome.”); id. 5752:18–5753:9 (discussing UPXD104 at 33, which states that foreclosure analysis needs to “consider[] how much of the market is available to rival sellers.”). Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on April 30, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on April 30, 2024, storage.courtlistener is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. storage.courtlistener

20% of All General Searches in the U.S. Go Through the Default on User-Downloaded Version of Chrome

Google's Monopoly: Defaults Have A Powerful Effect On Users’ Search Behavior

Protect People From Themselves: Reducing Default Risks in P2P Lending

If I would have to point out one of the most confusing Dispatchers in the world of Kotlin coroutines, that would be the Unconfined dispatchers. Called with Dispatchers.Unconfined when creating a coroutine scope, this a kind of dispatcher that doesn’t really care. The whole idea of the Unconfined dispatcher is simply to pick up a Thread for no other goal than to simply use it. There is no other criteria involved when using a Thread.Coroutines use a system called green threading or also known as user space threading. We can refer to routines as contructs that are designed to gain control of a Thread, but specifically they are managed by the schedulers to run in platform or system threads. By platform threads, we are talking about the threads accessible by the programming language or higher abstraction that we use in our development environment.When we talk about the unconfined dispatchers, it is important to understand what these terms are. And so let’s get clear to what is green threading and user space threading. These terms are used interchangeably. However, there is a very subtle difference: User space threading is used to emphasize that it is the user that schedules the threads. In other words, this is what we refer to when we start threads via our code. Green threading emphasizes on what goes on behind the curtain. Green threads are also called fibers and these are virtual threads that are multiplexed to be used on top of system threads. This is all something very difficult to visualize. But for the case of the Unconfined Dispatchers this is all we need to know about this part. Being aware of the existence of platform threads, virtual threads and system threads and how they work is important because the platform threads will then perform this multiplexing mechanism onto specific system threads and this is why in Kotlin, specifically, we can find dispatchers specifically to be used with the CPU, the Dispatchers.Default, dispatchers specific for IO operations called Dispatchers.IO and dispatchers specific for single threaded UI , such as Dispatchers.Main for other operations as alternatives to the Dispatchers.Unconfined context. Making tests using the Spring Framework we will very easily come across the fact that the Spring Framework uses Dispatchers.Unconfined. When I made it was generally said that Dispatchers.Unconfined were to be used in tests only due to their unpredictability. this video do not rely on a particular platform scheduling system oriented to a specific kind of Thread, it becomes very unpredictable how coroutines launched like this would perform. There were also mentions of the possibility that Dispatchers.Unconfined could eventually block the execution of the application in production code, but to be honest I have never ever seen that, even working so much with the Spring Framework for server-side programming as I currently do with Kotlin. And to top that up they mention precisely that, because of that risk, all nested coroutines form an event-loop. They explain that in their documentation here: Dispatchers.Unconfined https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-unconfined.html?embedable=true But hold on. Why is the Spring Framework using Dispatchers.Unconfined in their implementation instead of other Dispatchers like for example the Dispatchers.IO? And why not test this before anything? Well, first let’s have a look at an issue that was opened on GitHub about this: https://github.com/spring-projects/spring-framework/issues/32032?embedable=true I came across this subject when I was casually looking for something else and I bumped into another issue on StackOverflow: https://stackoverflow.com/questions/77810077/controller-code-using-unconfined-dispatcher-by-default?embedable=true Someone had found out that, for whatever reason, the Dispatchers.Unconfined was being used and so I created a service on my GitHub Repo here to prove that: https://github.com/jesperancinha/jeorg-spring-master-test-drives?embedable=true And this service is called car-parts-reactive and that is located in the root directory of the project: git clone https://github.com/jesperancinha/jeorg-spring-master-test-drives.git
cd car-parts-reactive
make b
make run The method we want to have a look at is this one in the controller CarController: @GetMapping("/break")
suspend fun getBreak(): String {
    println("Current Coroutine Context -> $coroutineContext")
    println("Current Coroutine Job -> ${coroutineContext.job}")
    println("Main Coroutine Context -> ${currentCoroutineContext()}")
    println("Main Coroutine Job -> ${currentCoroutineContext().job}")
    println("Current Thread -> ${Thread.currentThread()}")
    return "break"
} This method will print out a series of useful information to the console about the corroutine that has been called. The suspend function marked with the suspend modifier isn’t itself a coroutine, but it can only be called by coroutines in Kotlin. And that’s what happens when we call the method. This way we get access to the coroutine context and checkout what dispatcher is being used. Important to note is that using the currentCoroutineContext() function, we are accessing the coroutine context via a top level function in the kotlinx coroutines library. Using coroutineContext, we are accessing the getter of a value located in the kotlin standard library itself. They don’t share exactly the same implementation.In the root of the car-parts-reactive module we’ll find file generated-requests.http and if you are using IntellJ, you can easily make requests to the application with the code contents: ###
GET http://localhost:8080/break

###
GET http://localhost:8080/keys

###
GET http://localhost:8080/parts

###
GET http://localhost:8080/parts/list

###
GET http://localhost:8080/parts/suspend

###
GET http://localhost:8080/parts/correct When you have the application running, try to run a simple REST request against endpoint : http://localhost:8080/break There should be a result in the console similar to this: Current Coroutine Context -> [Context2{micrometer.observation=io.micrometer.observation.NoopObservation@52c86bb3, reactor.onDiscard.local=reactor.core.publisher.Operators$$Lambda$1234/0x000000080165d210@7166cb50}, MonoCoroutine{Active}@5474a700, Dispatchers.Unconfined]
Current Coroutine Job -> MonoCoroutine{Active}@5474a700
Main Coroutine Context -> [Context2{micrometer.observation=io.micrometer.observation.NoopObservation@52c86bb3, reactor.onDiscard.local=reactor.core.publisher.Operators$$Lambda$1234/0x000000080165d210@7166cb50}, MonoCoroutine{Active}@5474a700, Dispatchers.Unconfined]
Main Coroutine Job -> MonoCoroutine{Active}@5474a700
Current Thread -> Thread[#50,reactor-http-epoll-2,5,main] We can see in all counts that the dispatcher being used is the Dispatchers.Unconfined. If we go back to the issue that was created on GitHub, we’ll see that the answer to why the spring framework uses Dispatchers.Unconfined turns out to be the best solution for their cases, according to them. So what they mean, is that in spite of these dispatchers appear to be limited and restrictive, they apparently, and after testing are actually a very good fit for a reactive framework.Of course this is great to read because it makes it clear why actually, unconfined dispatchers are used in Spring.But let’s go back to the basics. I made a few quizzes about unconfined dispatchers and what I like about it is that they are still quite mysterious to me. And let’s get one thing clear before we move on. There can be some confusion regarding context and scope. Scope refers to where the coroutine is available and context to how it gets dispatched. There can be confusion about this because both terms are quite intimately connected to each other. For example, we cannot create a scope without a dispatcher and they go hand in hand. A scope allows me to launch coroutines with keywords like async and/or launch, but a context is related to how that coroutine gets assigned a Thread.Let’s make two quizzes. We start with this one in this video: https://www.youtube.com/shorts/7Rv_zcT_yPE?embedable=true In this video I show a simple implementation of some code that makes some calls and these different calls will print the words “master”, “mouse” and “cat” in different orders. The code is available here: https://github.com/jesperancinha/jeorg-kotlin-test-drives?embedable=true For this quiz, the code is available here: git clone https://github.com/jesperancinha/jeorg-kotlin-test-drives.git
cd jeorg-kotlin-coroutines/coroutines-crums-group-1
make b And the code is this one: private suspend fun runUnconfinedCoroutinesTest() {
    logger.infoTextSeparator("Unconfined means that all coroutines will execute concurrently on the starting thread in the scope of the parent thread")
    val job = CoroutineScope(Dispatchers.Unconfined).launch {
        launch {
            logger.infoThread("Cat Before thread ==> ${Thread.currentThread()}")
            delay(100)
            logger.info("This is cat @ ${LocalDateTime.now()}")
            logger.info("Cat context $coroutineContext")
            logger.infoThread("Cat After Resume thread ==> ${Thread.currentThread()}")
        }
        launch {
            logger.info("This is mouse @ ${LocalDateTime.now()}")
            logger.info("Mouse context $coroutineContext")
        }
        logger.info("This is master @ ${LocalDateTime.now()}")
        logger.info("Master context $coroutineContext")
        logger.infoThread(Thread.currentThread())

    }
    job.join()
} When we run this code, many things can happen, but one thing we can predict is how the logs are going to work out in the console. One thing about unconfined dispatchers is that they use the same context, same dispatchers, on the first sub coroutines. If these coroutines need to suspend, they may or may not return to the original Thread they were sharing. In the code above they will most likely not return to the original thread. Nesting in coroutines follows some very important rules as mentioned in their documentation: kotlinlang.org So this is the same as saying that the initial call executes in the same continuation in the same call-frame. This also means that the first 3 launches will run concurrently. The launch that logs a cat does this too, but beacause it has a delay, it will resume either in the same Thread or another thread. So this means that Mouse and Master will be the first things to see in the log and Cat will be the last log in the console. We can see all of this in this log sample: This is master @ 2024-03-21T18:49:00.661284475
Master context [StandaloneCoroutine{Active}@6ce139a4, Dispatchers.Unconfined]
Thread[#1,main,5,main]
Master After Resume thread ==> Thread[#1,main,5,main]
Cat Before thread ==> Thread[#1,main,5,main]
This is mouse @ 2024-03-21T18:49:00.703936722
Mouse context [StandaloneCoroutine{Active}@433d61fb, Dispatchers.Unconfined]
Mouse After Resume thread ==> Thread[#1,main,5,main]
This is cat @ 2024-03-21T18:49:00.801217959
Cat context [StandaloneCoroutine{Active}@52c68062, Dispatchers.Unconfined]
Cat After Resume thread ==> Thread[#28,kotlinx.coroutines.DefaultExecutor,5,main] And this explains the answer I give to this quiz on this video: https://www.youtube.com/shorts/MGxvkW0t8QM?embedable=true But moving on. I have another quiz for you and it is this one on this video: https://www.youtube.com/shorts/LEyEJkJA3xE?feature=share&embedable=true The code for this quiz is available here: git clone https://github.com/jesperancinha/jeorg-kotlin-test-drives.git
cd jeorg-kotlin-coroutines/jeorg-kotlin-coroutines-unconfined
make b And this is the class we are discussing: object UnconfinedCoroutineLauncher {
    private val logger = object {
        fun info(logText: Any?) = ConsolerizerComposer.out().yellow(logText)
        fun infoBefore(logText: Any?) = ConsolerizerComposer.out().green(logText)
        fun infoAfter(logText: Any?) = ConsolerizerComposer.out().red(logText)
        fun infoTitle(logText: String) = ConsolerizerComposer.outSpace()
            .cyan(ConsolerizerComposer.title(logText))
    }

    @JvmStatic
    fun main(args: Array<String> = emptyArray()) = runBlocking {
        logger.infoTitle(
            "Unconfined Coroutines scope tests / There are currently ${
                Runtime.getRuntime().availableProcessors()
            } CPU's available"
        )
        CoroutineScope(Dispatchers.Unconfined).launch {
            launch {
                logger.info("Running on context $coroutineContext")
                logger.infoBefore("Siamese Cat is launching on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
                delay(1)
                logger.infoAfter("Siamese Cat just ran on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
            }
            launch {
                logger.info("Running on context $coroutineContext")
                logger.infoBefore("Mouse is launching on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
                delay(20)
                logger.infoAfter("Mouse just ran on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
            }
            launch {
                logger.info("Running on context $coroutineContext")
                logger.infoBefore("Maine Coon is launching on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
                delay(30)
                logger.infoAfter("Maine Coon is just ran on Thread-${Thread.currentThread().name} with id ${Thread.currentThread().threadId()}")
            }
        }.join()
    }
} The best way to pick one or more options form the one I give in the quiz, is to look at the order the animals start. In this case the can all start in random orders. However they will all share the same thread because they are just being launched from that call stack. This way, the Siamese Cat, the Mouse and the Main Coon need to share he same Thread number on those calls and so that eliminates already options B and D. The Siamese cat only has a delay of 1 ms and that means that, although seemingly unlikely, option A is still very possible. It is actually very likely that this coroutine starts and ends before any of the other two start. 1 ms is just too much of a short time. We have to consider that possibility as well. And this is why the right answers to this questions are A and C, and this is only one example of that result: Running on context [StandaloneCoroutine{Active}@4de5031f, Dispatchers.Unconfined]
Siamese Cat is launching on Thread-main with id 1
Siamese Cat just ran on Thread-main with id 1
Running on context [StandaloneCoroutine{Active}@691a7f8f, Dispatchers.Unconfined]
Mouse is launching on Thread-main with id 1
Running on context [StandaloneCoroutine{Active}@50a7bc6e, Dispatchers.Unconfined]
Maine Coon is launching on Thread-main with id 1
Mouse just ran on Thread-kotlinx.coroutines.DefaultExecutor with id 21
Maine Coon is just ran on Thread-kotlinx.coroutines.DefaultExecutor with id 21 Find the video answer to this . quiz here My idea with this article is to show some interesting cases I found with . You may find these issues while working with Kotlin coroutines and very likely a lot of people will tell you just to use the Default dispatcher. That can lead to a miscommunication problem. There is such a thing called , which is specific for CPU operations. When people say that when in doubt, use the default dispatcher, they probably do not mean the context. Make sure to double check, because, especially if you are working in server-side programming with certain frameworks, what they probably mean is that you shouldn’t use any specific dispatchers. Most of frameworks like the Spring Framework already offer support to use suspend functions and so your concern as a developer is for the most cases only to implement the suspend functions and not use any specific context. Use the default of course and that is, in Spring, the . Have a good one everyone! Dispatchers.Unconfined Dispatchers.Default Dispatchers.Default Dispatchers.Unconfined Also published . here

They Said to Use the Default Dispatchers but I Found it Was Unconfined

The checkbox is one of the most useful inputs for building dynamic apps with React. In this guide, we will see how to make the checkbox checked (or unchecked) by default. defaultChecked Prop As a React developer, you are probably familiar with JSX. It’s a templating language to easily develop UIs in React. Its biggest advantage is that most elements and development processes are very similar to HTML. Similar to HTML, you can set the attribute on checkbox inputs. It needs to be set to a Boolean value. If set to , the checkbox will be automatically selected. If the value is , or there’s no default at all, the checkbox will not be automatically selected. defaultChecked true false Let’s look at an example: <input type="checkbox" defaultChecked="true" /> This is a simple uncontrolled checkbox. The attribute is set to a Boolean value . In the real world, is often set to a Boolean value from the state, or a complex condition that evaluates to or . defaultChecked true defaultChecked true false Set the Default Value of a Controlled Checkbox in React In most cases, it’s best to create controlled inputs in React. These are inputs that get their value from the state. Changes to the checkbox also update the state. Let’s look at a of a controlled checkbox: live demo import "./styles.css";
import { useState } from "react";
export default function App() {
 const [checkbox, setCheckbox] = useState(true);
 const handleChange = (e) => setCheckbox(e.target.checked);
 return (
   <div>
    <input type="checkbox" defaultChecked="true" onChange={handleChange} />
    <p>Checkbox is {checkbox ? "checked" : "unchecked"}</p>
    </div>
  );
} style="width:100%; height: 500px; border:0; border-radius: 4px; overflow:hidden;" 

 title="clever-ives" 

 allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking" 

 sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts" When it first loads, the checkbox is selected because is set to . defaultChecked true The event handler tracks change events, accesses the current status (checked or not), and stores it in the state. In this case, we do not set the attribute on an input. attribute results in less code and works the same. value defaultChecked We can keep track of the current value of the checkbox and use it for conditional styling, rendering, and other dynamic features in React. For example, you can use conditional styling to implement the dark mode. If you’d like to learn more, check out my . I’ve published several articles about working with inputs in React. React guides with examples

How to Set A Default Checkbox Value in React

One of the key features of the Spring Boot framework is the built-in support for embedded servers. It includes support for embedded Tomcat, Jetty, and Undertow servers. This means you don’t need any external web servers and no need to deploy WAR files anymore. The embedded Tomcat server is available through the dependency. spring-boot-starter-web However, if you want Jetty or Undertow servers then you can include or dependencies. spring-boot-starter-jetty spring-boot-starter-undertow This article explains how to replace the default embedded Tomcat with Jetty or Undertow servers. https://youtu.be/1gEoiMVULt4?si=RVOx-P3o65KPN2-p&embedable=true Replace Tomcat With the Jetty in Spring Boot To use the embedded Jetty server instead of Tomcat, you need to exclude the from and include the dependency. Also, you will need to exclude the default added spring-boot-starter-tomcat dependency. spring-boot-starter-tomcat spring-boot-starter-web spring-boot-starter-jetty For Spring Boot Version 2.x.x For , make the following changes to your file. Gradle build.gradle dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web') {
        exclude group:'org.springframework.boot', module:'spring-boot-starter-tomcat'
    }
    implementation 'org.springframework.boot:spring-boot-starter-jetty'
} If you’re using build tools, you need to add this to your file. Maven pom.xml <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency> For Spring Boot Version 3.x.x The above configuration works for Spring Boot version 2.x, but it will throw the following error if you’re using the latest Spring Boot version 3.x. java.lang.ClassNotFoundException: jakarta.servlet.http.HttpSessionContext 
with Spring Boot 3 and Jetty server This is because Jetty does not yet support Servlet 6.0. To use Jetty with Spring Boot 3.0, you will have to downgrade the Servlet API to 5.0. You can use the property to do so. jakarta-servlet.version Ref: Spring-Boot-3.0-Migration-Guide ext['jakarta-servlet.version'] = '5.0.0'
dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web')
    implementation 'org.springframework.boot:spring-boot-starter-jetty'
    modules {
        module("org.springframework.boot:spring-boot-starter-tomcat") {
            replacedBy("org.springframework.boot:spring-boot-starter-jetty")
        }
    }
} If you’re using build tools, you need to add this to your file. Maven pom.xml <properties>
    <java.version>17</java.version>
    <jakarta-servlet.version>5.0.0</jakarta-servlet.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <exclusions>
            <exclusion>
                <artifactId>spring-boot-starter-tomcat</artifactId>
                <groupId>org.springframework.boot</groupId>
            </exclusion>
        </exclusions>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jetty</artifactId>
    </dependency>
</dependencies> Replace Tomcat With Undertow in Spring Boot To use Undertow instead of Tomcat, first, you need to exclude the spring-boot-starter-tomcat from spring-boot-starter-web. Then you should add the undertow starter as shown here. For , make the following changes to your file. Gradle build.gradle dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web') {
        exclude group:'org.springframework.boot', module:'spring-boot-starter-tomcat'
    }
    implementation 'org.springframework.boot:spring-boot-starter-undertow'
} If you’re using build tools, you need to add this to your file. Maven pom.xml <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency> Also published here

Stories, News & Mentions about DEFAULT

Categories

Trending Topics

Stories, News & Mentions about DEFAULT

Default’s Stories on HackerNoon

Categories

Trending Topics