Gradle 8.6-rc3 has been released
This release features support for custom encryption keys for the configuration cache, several improvements to build init, and updated build authoring APIs.
Additionally, this release provides more helpful error and warning messages and a new API for IDE integrators.
Gradle 8.6-rc2 has been released
This release features support for custom encryption keys for the configuration cache, several improvements to build init, and updated build authoring APIs.
Additionally, this release provides more helpful error and warning messages and a new API for IDE integrators.
Gradle 8.6-rc1 has been released
This release features support for custom encryption keys for the configuration cache as well as more helpful error and warning messages.
Additionally, this release comes with several improvements to build init and to build authoring for build engineers and plugin authors.
Gradle 8.5 has been released
Gradle now supports running on Java 21.
This release features Kotlin DSL improvements, including faster first use and version catalog support in precompiled Kotlin script plugins.
Additionally, this release comes with more helpful error and warning messages, improvements to build init, dependency verification and several new APIs for build and plugin authors. See the full release notes for details.
Gradle 8.5-rc4 has been released
Gradle now supports running on Java 21.
This release features Kotlin DSL improvements, including faster first use and version catalog support in precompiled Kotlin script plugins.
Additionally, this release comes with more helpful error and warning messages, improvements to build init, dependency verification and several new APIs for build and plugin authors. See the full release notes for details.
Gradle 8.5-rc3 has been released
Gradle now supports running on Java 21.
This release features Kotlin DSL improvements, including faster first use and version catalog support in precompiled Kotlin script plugins.
Additionally, this release comes with more helpful error and warning messages, improvements to build init, dependency verification and several new APIs for build and plugin authors. See the full release notes for details.
Gradle 8.5-rc2 has been released
Gradle now supports running on Java 21.
This release features Kotlin DSL improvements, including faster first use and version catalog support in precompiled Kotlin script plugins.
Additionally, this release comes with more helpful error and warning messages, improvements to build init, dependency verification and several new APIs for build and plugin authors. See the full release notes for details.
Gradle 8.5-rc1 has been released
Gradle now supports running on Java 21.
This release features Kotlin DSL improvements, including faster first use and version catalog support in precompiled Kotlin script plugins.
Additionally, this release comes with more helpful error and warning messages, improvements to build init, dependency verification and several new APIs for build and plugin authors. See the full release notes for details.
Gradle 8.4 has been released
This release features several improvements for JVM-based projects. Java 21 is now supported for compiling, testing, and running such projects. Faster Java compilation with persistent compiler deamons now also works on Windows. This release also brings a simpler way to create dependency configurations for specific roles. For more improvements for JVM-based projects, see the full release notes below.
Kotlin DSL, which recently became the default DSL for new projects, continues to receive improvements. The Kotlin version embedded in Gradle has been updated to Kotlin 1.9.10. The simple property assignment with the = operator has been promoted to stable. In addition, the reference documentation for the Kotlin DSL now provides links back to sources hosted on GitHub.
In addition, this release addresses two security vulnerabilities:
- Incorrect permission assignment for symlinked files used in copy or archiving operations
- Possible local text file exfiltration by XML External entity injection
Gradle 8.4-rc3 has been released
This release features several improvements for JVM-based projects. Java 21 is now supported for compiling, testing, and running such projects. Faster Java compilation with persistent compiler deamons now also works on Windows. This release also brings a simpler way to create dependency configurations for specific roles. For more improvements for JVM-based projects, see the full release notes below.
Kotlin DSL, which recently became the default DSL for new projects, continues to receive improvements. The Kotlin version embedded in Gradle has been updated to Kotlin 1.9.10. The simple property assignment with the = operator has been promoted to stable. In addition, the reference documentation for the Kotlin DSL now provides links back to sources hosted on GitHub.
Gradle 8.4-rc2 has been released
This release features several improvements for JVM-based projects. Java 21 is now supported for compiling, testing, and running such projects. Faster Java compilation with persistent compiler deamons now also works on Windows. This release also brings a simpler way to create dependency configurations for specific roles. For more improvements for JVM-based projects, see the full release notes below.
Kotlin DSL, which recently became the default DSL for new projects, continues to receive improvements. The Kotlin version embedded in Gradle has been updated to Kotlin 1.9.10. The simple property assignment with the = operator has been promoted to stable. In addition, the reference documentation for the Kotlin DSL now provides links back to sources hosted on GitHub.
Gradle 8.4-rc1 has been released
This release features several improvements for JVM-based projects. Java 21 is now supported for compiling, testing, and running such projects. Faster Java compilation with persistent compiler deamons now also works on Windows. This release also brings a simpler way to create dependency configurations for specific roles. For more improvements for JVM-based projects, see the full release notes below.
Kotlin DSL, which recently became the default DSL for new projects, continues to receive improvements. The Kotlin version embedded in Gradle has been updated to Kotlin 1.9.10. The simple property assignment with the = operator has been promoted to stable. In addition, the reference documentation for the Kotlin DSL now provides links back to sources hosted on GitHub.
Gradle 8.3 has been released
This release features the support for persistent Java compiler daemons to speed up Java compilation. Gradle will also use less memory for dependency resolution. The effect is significant, particularly for large builds such as Android builds.
Gradle now supports running on Java 20.
For Kotlin DSL, build authors can try out the Kotlin K2 compiler for build logic with some limitations. See the Kotlin DSL dedicated section for more information.
This release also brings several usability improvements, including better CodeNarc output, a dry run mode for test execution, improved output for task options, and upgraded SSL support.
You can create a transform rule (iirc, might be one of the other rules, can’t check right now) that changes the destination port as long as you’re using Cloudflare’s proxy, no need for stuff like srv records.
edit; alternatively you can use cloudflare’s tunnels feature if forwarding doesn’t work
It doesn’t prove you’re not a bot though, only that the request is coming from a ‘genuine device’. You just need to pipe your malicious requests through a ‘real browser’ to get them approved and you’re set.
Could’ve sworn I saw it in an article or post on here somewhere… but of course now that I actually need the post I can’t find it. Doesn’t really matter though, Chrome can unfortunately push standards through even if others don’t approve, just due to their sheer size alone.
Cloudflare registrar or Porkbun are my goto's. Keep in mind that Cloudflare registrar currently requires you to use their (free) DNS service, you can't change the nameservers yet.
It’s ridiculous how nowadays a lot of hardware car features are locked behind a simple software switch. Feels like both a massive waste of resources for people that don’t buy the upgrades, and like having to pay for a feature that is already physically present in your car. Software-only upgrades like full self driving are understandable, hardware upgrades locked behind a software gate aren’t.
[cross-posted from my reply to the same article on c/news]
It's ridiculous how nowadays a lot of hardware car features are locked behind a simple software switch. Feels like both a massive waste of resources for people that don't buy the upgrades, and like having to pay for a feature that is already physically present in your car. Software-only upgrades like full self driving are understandable, hardware upgrades locked behind a software gate aren't.
Canvas rendering differs slightly depending on a lot of factors like operating system, browser, installed fonts, and many others. This information can be used to uniquely identify and track your machine across the web, even if you have stuff like cookies blocked and switch IPs. Just outright blocking canvas access attempts to prevent this. Keep in mind that while it can help prevent against canvas tracking, it can also be used as yet another variable to uniquely identify your browser, 'has canvas blocking enabled', just like blocking cookies, do not track requests, etc...
Luckily, other browser manufacturers (Mozilla, Vivaldi, Brave, and even the WWWC) have already spoken out against this proposal. Google loves marketing it as ‘optional’, which it obviously won’t be once implemented. A system like this would be very dangerous for smaller browsers, as it’s incredibly vague who decides what authorities would be allowed to verify browsers.
Additionally, this is presented as a way to remove captchas from the web by proving a request is coming from genuine hardware. However, this proves absolutely nothing about a request being genuine or non-spam. The only thing this proves is that it was created by a ‘genuine device’, so all a malicious user would have to do is to (automatically) send the request via a verified device and they’d pass the check.
I'm really excited to see the technical changes, specifically the move towards a more data-driven system. This should make it a lot easier for servers to change stuff like biomes when a player is already playing, especially on larger networks. Currently you'd have to set the biomes on join, without a way to update them or make them "sub-server" specific.
The datapack changes are also very nice to see, hopefully this can help people write some more performant functions _