I've been writing Java for 16 years, and I feel like the proposed "on-ramp" features should cater not just to beginners, but also to seasoned developers working on larger applications. Here are my hopes for improvements:
1. **Integrated Build System**: A user-friendly build system within the Java SDK, similar to Go's, so that it's easy for anyone to get started without needing complex configurations.
2. **CLI Argument Parsing Library**: A better standard library for parsing command-line arguments, as the current options can be quite challenging.
3. **Enhanced HTTP Server**: The existing Sun HTTP server needs to be elevated to standard library status; it shows great potential but needs to be production-ready.
4. **Built-in JSON Parser**: A dependency-free JSON parsing library that is efficient and straightforward to use should be included.
5. **Native Executable Support**: Simplifying the process of building native executables for various platforms, just like Go does.
6. **Watch Mode**: A first-class watch mode that detects changes and reloads automatically, improving development speed.
7. **Testing Framework**: A high-performance testing framework included in the standard library would make Java much smoother for writing unit tests.
8. **Unified SDK Manager**: An SDK manager built into Java to handle installations and versions seamlessly, reducing setup complexity for both new developers and CI/CD pipelines.
These features might seem small but they're crucial for making Java more accessible. What features do you wish to see under the on-ramp project?
2 Answers
While some of these points could be helpful, a lot of existing tools like JUnit and SDKMAN already work well outside the JDK. Adding them directly to the JDK doesn’t necessarily improve things, especially since JDK updates could hinder third-party updates. It's not that hard to set up tools like Maven or Gradle, and adding everything to the core library could clutter it unnecessarily. I vote for keeping the existing ecosystem flexible rather than forcing standardization.
Some of these ideas are interesting, but integrating a new build system into the JDK could be challenging. The community has pretty much settled on Maven and Gradle, so creating a new system might not have a big payoff. Plus, handling third-party dependencies within the JDK might complicate things even further. Regarding the JSON parsing library, I've heard there are plans for that already. Until they materialize, Jackson works just fine for most cases. I think the JDK should focus on polishing existing tools rather than adding new ones.
Totally agree! The flexibility allows developers to choose what suits their projects best. Forcing one path could limit innovation.