openjdk · davidalayachew · Mar 17, 2025 · Mar 17, 2025 · Mar 19, 2025 · Mar 19, 2025
diff --git a/site/_index.md b/site/_index.md
@@ -21,12 +21,16 @@ have links to earlier JEPs for the feature, as appropriate.
 Currently in progress:
 
 -   [468: Derived Record Creation (Preview)](https://openjdk.org/jeps/468)
+    - [FAQ](faq/derived_record_creation)
 
 Currently in preview:
 
 -   [495: Simple Source Files and Instance Main Methods (Fourth Preview)](https://openjdk.org/jeps/495) (previous: [445](https://openjdk.org/jeps/445), [463](https://openjdk.org/jeps/463), [477](https://openjdk.org/jeps/477))
+    - [FAQ](faq/simple_source_files_and_instance_main_methods)
 -   [494: Module Import Declarations (Second Preview)](https://openjdk.org/jeps/494) (previous: [476](https://openjdk.org/jeps/476))
+    - [FAQ](faq/module_imports)
 -   [492: Flexible Constructor Bodies (Third Preview)](https://openjdk.org/jeps/492) (previous: [447](https://openjdk.org/jeps/447), [482](https://openjdk.org/jeps/482))
+    - [FAQ](faq/flexible_constructor_bodies)
 -   [488: Primitive Types in Patterns, <code>instanceof</code>, and <code>switch</code> (Second Preview)](https://openjdk.org/jeps/488) (previous: [455](https://openjdk.org/jeps/455))
 
 Delivered:
@@ -44,7 +48,7 @@ Delivered:
 -   [323: Local-Variable Syntax for Lambda Parameters](https://openjdk.org/jeps/323)
 -   [286: Local-Variable Type Inference (<code>var</code>)](https://openjdk.org/jeps/286)
     -   [Style Guidelines](guides/lvti-style-guide)
-    -   [FAQ](guides/lvti-faq)
+    -   [FAQ](faq/local_variable_type_inference)
 
 On hold:
 

diff --git a/site/faq/derived_record_creation.md b/site/faq/derived_record_creation.md
@@ -0,0 +1,22 @@
+
+## Derived Record Creation
+### Frequently Asked Questions {.subtitle}
+
+#### Why don't you just use named parameters instead? {#named_parameters}
+- ["having a named parameter mechanism for records, but for nothing else \[...\] might seem "better than nothing", \[but\] having two different ways to do something, but one of them only works in narrow situations, is as likely to be frustrating than beneficial."](https://mail.openjdk.org/pipermail/amber-dev/2024-February/008643.html)
+- ["The problem with named parameters is that \[...\] you \[must\] give up separate compilation if you wish to use named parameters. That's too high a price"](https://old.reddit.com/r/java/comments/137wdql/jep_441_pattern_matching_for_switch_formally/jj909dq/?context=3)
+    - [Archived Link](https://web.archive.org/web/20250325013349/https://old.reddit.com/r/java/comments/137wdql/jep_441_pattern_matching_for_switch_formally/jj909dq/?context=3)
+- [_\(See more here\)_](https://mail.openjdk.org/pipermail/amber-dev/2024-November/009090.html)
+
+#### Why don't you just use default parameters instead? {#default_parameters}
+- ["\[This introduces\] painful questions about binary compatibility ("surely I can add another parameter with a default?")"](https://mail.openjdk.org/pipermail/amber-dev/2024-January/008507.html)
+- ["Default parameters are \[significantly\] more complicated \[...\] It would intrude into \[...\] already complex areas."](https://old.reddit.com/r/java/comments/v97r5t/with_for_records_brian_goetz/ibwfayd/)
+    - [Archived Link](https://web.archive.org/web/20250325002437/https://old.reddit.com/r/java/comments/v97r5t/with_for_records_brian_goetz/ibwfayd/)
+- [_\(See more here\)_](https://mail.openjdk.org/pipermail/amber-dev/2024-November/009090.html)
+
+#### Why don't you just force unique names? The shadowing rules are confusing in this context. {#confusing_shadowing_rules}
+- ["these names _must_ be accessible because they are fixed by the record declaration."](https://mail.openjdk.org/pipermail/amber-dev/2024-April/008738.html)
+
+#### How will changing the record components affect binary compatibility? {#binary_compatibility}
+- ["_Adding, deleting, changing, or reordering record components in a record class may break compatibility with pre-existing binaries that are not recompiled; such a change is not recommended for widely distributed record classes._"](https://mail.openjdk.org/pipermail/amber-dev/2024-April/008757.html)
+- [\(_See more here._\)](https://mail.openjdk.org/pipermail/amber-dev/2024-April/008760.html)
diff --git a/site/faq/flexible_constructor_bodies.md b/site/faq/flexible_constructor_bodies.md
@@ -0,0 +1,14 @@
+
+## Flexible Constructor Bodies
+### Frequently Asked Questions {.subtitle}
+
+#### Why do we need this feature? What is so important about it? {#why_is_this_a_jep}
+- [_Value Classes depend on this feature, so enabling this feature for all classes allows Value Classes to not be as much of an exception._](https://openjdk.org/jeps/401#Early--late-construction)
+
+#### Why don't you just use a Factory Method? {#factory_methods}
+- ["Constructors were designed to allow validation. This change makes supporting that use-case easier"](https://old.reddit.com/r/java/comments/12rvfjz/jep_447_statements_before_super/jgwq8v1/?context=3)
+    - [Archived Link](https://web.archive.org/web/20250330013638/https://old.reddit.com/r/java/comments/12rvfjz/jep_447_statements_before_super/jgwq8v1/?context=3)
+
+#### How is this related to the `this-escape` warning? {#this-escape}
+- ["\[Both attempt\] to prevent a superclass constructor from invoking an overridden method that would then see uninitialized subclass fields \[while granting different forms of freedom\]."](https://mail.openjdk.org/pipermail/amber-dev/2025-March/009266.html)
+    - [_(See here to learn more about `this-escape` -- future enhancements may not be contained in this link)_](https://bugs.openjdk.org/browse/JDK-8299995)
diff --git a/site/guides/lvti-faq.md → site/faq/local_variable_type_inference.md b/site/guides/lvti-faq.md → site/faq/local_variable_type_inference.md
diff --git a/site/faq/module_imports.md b/site/faq/module_imports.md
@@ -0,0 +1,18 @@
+
+## Module Import Declarations
+### Frequently Asked Questions {.subtitle}
+
+#### What about class name clashes? Like `java.util.List` and `java.sql.List`? {#class_name_clash}
+- ["Compiler error \(which you can then resolve with, say, `import java.sql.Date`\)"](https://old.reddit.com/r/java/comments/1bqneuy/jep_draft_module_import_declarations_preview/kx4usz8/)
+    - [Archived link](https://web.archive.org/web/20250319015257/https://old.reddit.com/r/java/comments/1bqneuy/jep_draft_module_import_declarations_preview/kx4d3dk/)
+
+#### Why modules specifically? {#why_modules_specifically}
+- [\[The\] goal is to align the dependency granularity with the source code.](https://old.reddit.com/r/java/comments/1bqneuy/jep_draft_module_import_declarations_preview/kx7uzth/)
+    - [Archived link](https://web.archive.org/web/20250319015802/https://old.reddit.com/r/java/comments/1bqneuy/jep_draft_module_import_declarations_preview/kx7uzth/)
+- [`import module M` in your sources should align with \[...\] `requires M` in your module-info.java]()
+    - [Archived link](https://web.archive.org/web/20250319015802/https://old.reddit.com/r/java/comments/1bqneuy/jep_draft_module_import_declarations_preview/kx7uzth/)
+
+#### Why do some modules give me an error when trying to import them, like `import module java.se`?
+- ["If your program is in the unnamed module, then its 
+environment is the default set of root modules for the unnamed module \[...\] java.se is no longer (since JDK 11) in 
+the default set of root modules for the unnamed module."](https://mail.openjdk.org/pipermail/amber-spec-observers/2024-July/004451.html)
diff --git a/site/faq/simple_source_files_and_instance_main_methods.md b/site/faq/simple_source_files_and_instance_main_methods.md
@@ -0,0 +1,13 @@
+
+## Simple Source Files and Instance Main Methods
+### Frequently Asked Questions {.subtitle}
+
+#### Why don't you just get rid of `void main()` too? {#get_rid_of_void_main}
+- ["The semantics of a field and a local variable are very different"](https://mail.openjdk.org/pipermail/amber-dev/2024-May/008767.html)
+
+#### Why don't you just add `readInt/readDouble` to `java.io.IO`? {#read_nums_too}
+- ["Methods that are automatically imported in this way _effectively become part of the langauge_.  The bar for that is very high."](https://mail.openjdk.org/pipermail/amber-dev/2024-November/009039.html)
+- ["Because it greatly complicates the "reading state" that has to be understood by the user"](https://mail.openjdk.org/pipermail/amber-dev/2024-November/009033.html)
+
+#### Why don't you just static import all of `java.lang`? {#static_import_java_lang}
+- ["It creates a perverse incentive to put MORE stuff in java.lang, just to get the importing."](https://mail.openjdk.org/pipermail/amber-dev/2025-January/009200.html)