Re-word g3doc/limitations slightly and re-order
@@ -12,16 +12,6 @@ The main reason is that code that uses reflection hinders global dead code
removal. On the other hand code generation could be a substitute for many tasks
that would normally be accomplished by the use of reflection.
-## JRE Emulation
-
-J2CL emulates a substantial portion of the Java Standard Library (a.k.a JRE).
-However it's not feasible or practical to support all of the APIs in the web
-platform; APIs like `java.net.*` are intentionally left out.
-
-Shared code that uses these APIs can work around this limitation by
-[super-sourcing](best-practices.md#super-sourcing-writing-platform-specific-code)
-the classes and providing an alternative implementation specific for J2CL.
-
## No Support for Enum Reflective APIs
J2CL doesn't support `Class.getEnumConstants` and `Enum.valueOf` APIs.
@@ -33,6 +23,16 @@ overhead for using language primitives to discourage people from writing native
code for simple stuff only for performance considerations. Having
JavaScript-like array semantics help that story.
+## Limitations of JRE Emulation
+
+J2CL emulates a substantial portion of the Java Standard Library (a.k.a JRE).
+However it's not feasible nor practical to support all of the APIs in the web
+platform; APIs like `java.net.*` are intentionally left out.
+
+Shared code that uses these APIs can work around this limitation by
+[super-sourcing](best-practices.md#super-sourcing-writing-platform-specific-code)
+the classes and providing an alternative implementation specific for J2CL.
+
## Minor Semantic Differences
- **Switch on enum type does not trigger class initialization (`clinit`)**.
