JHipster VS Auto

An easy way to get a pre-configured Keycloak instance is to use JHipster's jhipster-sample-app-oauth2 application. It gets updated with every JHipster release. You can clone it with the following command:

provider "auth0" { domain = "https://" debug = false } # Create a new Auth0 application for the JHipster app resource "auth0_client" "java_ms_client" { name = "JavaMicroservices" description = "Java Microservices Client Created Through Terraform" app_type = "regular_web" callbacks = ["http://localhost:8080/login/oauth2/code/oidc"] allowed_logout_urls = ["http://localhost:8080"] oidc_conformant = true jwt_configuration { alg = "RS256" } } # Configuring client_secret_post as an authentication method. resource "auth0_client_credentials" "java_ms_client_creds" { client_id = auth0_client.java_ms_client.id authentication_method = "client_secret_post" } # Create roles for the JHipster app resource "auth0_role" "admin" { name = "ROLE_ADMIN" description = "Administrator" } resource "auth0_role" "user" { name = "ROLE_USER" description = "User" } # Create an action to customize the authentication flow to add the roles and the username to the access token claims expected by JHipster applications. resource "auth0_action" "jhipster_action" { name = "jhipster_roles_claim" runtime = "node18" deploy = true code = <<-EOT /** * Handler that will be called during the execution of a PostLogin flow. * * @param {Event} event - Details about the user and the context in which they are logging in. * @param {PostLoginAPI} api - Interface whose methods can be used to change the behavior of the login. */ exports.onExecutePostLogin = async (event, api) => { const namespace = 'https://www.jhipster.tech'; if (event.authorization) { api.idToken.setCustomClaim(namespace + '/roles', event.authorization.roles); api.accessToken.setCustomClaim(namespace + '/roles', event.authorization.roles); } }; EOT supported_triggers { id = "post-login" version = "v3" } } # Attach the action to the login flow resource "auth0_trigger_actions" "login_flow" { trigger = "post-login" actions { id = auth0_action.jhipster_action.id display_name = auth0_action.jhipster_action.name } } # Create a test user. You can create more users here if needed resource "auth0_user" "test_user" { connection_name = "Username-Password-Authentication" name = "Jane Doe" email = "[email protected]" email_verified = true password = "passpass$12$12" # Don't set passwords like this in production! Use env variables instead. lifecycle { ignore_changes = [roles] } } resource "auth0_user_roles" "test_user_roles" { user_id = auth0_user.test_user.id roles = [auth0_role.admin.id, auth0_role.user.id] } output "auth0_webapp_client_id" { description = "Auth0 JavaMicroservices Client ID" value = auth0_client.java_ms_client.client_id } output "auth0_webapp_client_secret" { description = "Auth0 JavaMicroservices Client Secret" value = auth0_client_credentials.java_ms_client_creds.client_secret sensitive = true }

If you want a Spring backend with an Angular Frontend check out https://www.jhipster.tech. This is very nice for CRUD stuff.

Use https://www.jhipster.tech/

To test GitHub Actions, we need a new project which in this case I generated using JHipster with the configuration seen here:

exports.onExecutePostLogin = async (event, api) => { const namespace = 'https://www.jhipster.tech'; if (event.authorization) { api.idToken.setCustomClaim('preferred_username', event.user.email); api.idToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles); api.accessToken.setCustomClaim(`${namespace}/roles`, event.authorization.roles); } }

What you maybe asking for is something like vaadin or jhipster which marries the front with the backend. (I don't like them tbh but it worth mentioning)

You can try this stack https://www.jhipster.tech with generator for mobile app https://github.com/jhipster/generator-jhipster-ionic.

I like to use AutoService to make using Java's ServiceLoader easier.

I've also had great luck combining that with AutoValue to allow production vs test injections without the new Foo(thing, null, null, null, thing2, null, null) situation:

AutoValue has posted a new doc comparing itself to Java record classes. (Records were new in Java 16, or earlier with --enable-preview.)

That means I don't forget about fields (as can happen if you're just doing `person.setX()` all the time). It's easy to see what is what when reading it. I can delete fields I don't want to initialize at the time. Yes, maybe immutable objects are the One True Way, but C# lets me choose (I can label properties with an initializer `init` rather than a setter `set` and then they're immutable).

Kotlin offers stuff like this too because it's really useful toward creating code that's easy to create and maintain. Go also lets you initialize structs in a similar fashion.

Java has come back to us a decade or more late with records. They're not bad, but they're only offering one thing. They don't cover what C#, Kotlin, Go, and other languages have offered for so long.

The annoying thing about Java is that it doesn't feel pragmatic a lot of the time. It feels like the language hates stealing ideas from others. It's Java: people steal ideas from Java, not the other way around. People do crazy things just to get POJOs including Immutables (http://immutables.github.io), AutoValue (https://github.com/google/auto/), Lombok (https://projectlombok.org), Joda Beans (https://www.joda.org/joda-beans/), and maybe more. They generate lots of code at compile time or do funky runtime stuff.

It just feels like Java misses the pragmatic stuff and still kinda doesn't want to handle that. I feel a bit silly harping on things like POJOs and setting data on a new object, but that's a big part of day-to-day stuff and it definitely pushes users away from Java towards languages that seem "better" simply because they don't have Java's oddly strong attachment to not offering simple value objects. Yes, again, records do something - but it feels like Java ignored how people are using Kotlin, Go, C#, and more and didn't go for something that would have been as widely applicable and pragmatic as it could have been.

Java has a lot of great stuff like great GCs (yes), lots of cool research, great performance, and Project Loom is really exciting. I just wish the language would lean a little more practical.

The main disadvantage of Java is the boilerplate and the fact that you don't get cool metaprogramming features. The boilerplate can be reduced with tools like AutoValue. The lack of monkey patching and crazy SFINAE template shenanigans is that it is much easier to look at some piece of code and know what it's calling. You have static types, so you can jump to the method definition reliably (as opposed to Python), and there aren't many subtle syntax features that can trip you up (like lvalue vs rvalue references in C++). You can absolutely make a mess of Java with crazy frameworks, but the fact that the language itself has simple syntax means that nobody else in the organization can do anything too clever.

There is no way you can tell that's valid Common Lisp without actually compiling and executing the code in the json-reader.lisp file. When the compiler gets to (enable-json-syntax), it sees that it is a macro so it executes its code at compile-time. That code then redefines the meaning of the { and [ characters to be the start of JSON objects/arrays (instead of their normal meaning in Common Lisp), and installs code telling Common Lisp how to parse JSON syntax, which is triggered when those characters are encountered in input. The example-object function shows an example of using it. Finally, (disable-json-syntax) is another macro, also executed at compile time, which undoes those changes to the Common Lisp syntax.

Common Lisp did not invent the idea of allowing a program to dynamically alter the language syntax as it was being parsed; I believe the idea was first introduced in Maclisp, and from there spread to other LISP dialects (such as Franz Lisp and Interlisp) before finally being standardised in Common Lisp. The originators of Scheme intentionally decided to leave this feature out, but some implementations/descendants of Scheme have added it back in, such as Racket [1], Guile [2], and Chicken Scheme [3]. Other Lisp-family languages (such as Clojure or Emacs Lisp) have resisted calls to add it, despite encouragement from certain quarters.

Earlier you spoke of "Tcl's lack of a grammar up against Scheme, Lisp", but if runtime-extensible syntax is a form of "lack of a grammar", then many Lisp family languages lack grammar too.

Another language for which this is true (albeit to a significantly lesser degree), is Java. With Java, you can run arbitrary code at compile time by defining an annotation processor. The annotation processor code is run when the annotation is encountered. The annotation processor is allowed to issue compilation errors. It can also generate more source code for additional classes, which gets added to the compilation process, and your program may refer some of those generated classes, and hence need that generated code to compile–for an example see [4] from the Google AutoValue docs, where the "AutoValue_Animal" class being constructed in the create() method is dynamically generated by a processor which is triggered by the @AutoValue annotation. So, if your Java program contains annotations with an associated processor, and if you define "syntactically correct" as "compiles without any errors", then you can't know if the Java program is syntactically correct without executing arbitrary Java code.

[0] https://gist.github.com/chaitanyagupta/9324402

[1] https://docs.racket-lang.org/reference/Reader_Extension.html

[2] https://www.gnu.org/software/guile/manual/html_node/Reader-E...

[3] https://wiki.call-cc.org/man/5/Module%20(chicken%20read-synt...

[4] https://github.com/google/auto/blob/master/value/userguide/i...

Reminds me of Google’s AutoValue: https://github.com/google/auto/tree/master/value

Records where you can, and because Lombok is controversial, Immutables is the other alternative (or autovalue). Actually, all code generation tools are fantastic: Immutables, MapStruct, jOOQ...

Via Lombok, yes, which, as of now, is a default plugin in Idea, which everyone is using anyway. If you don't like Lombok particularly (and god knows, I can't imagine why), there is an alternative made by Google called Auto. Or you can use Scala, which has some features like that natively and is 100% interoperable with Java (meaning you can make a new Scala file within the current project and start using it right away). I imagine Kotlin also has some syntax sugar; however, I am not familiar with Kotlin very well.

For immutable value types, AutoValue[1] is a nice library for automating this. Lombok[2] is also popular, but a lot of orgs avoid it because it has some pretty deep dependencies on implementation details of the JDK that aren't guaranteed to be stable across releases. It seems well-maintained in practice, thoguh. Once Java records[3] are out of preview, they will probably be the preferred approach, but it will be a while before most teams are on a version of the JDK that supports them.

For mutable objects, the notion of equality is hairy in general, because what you want often depends on why you'd be comparing the two objects. You might have two mutable objects that can be meaningfully compared in your business logic, but absolutely should not be used as keys in a map. Often you can satisfy your goals by implementing a separate method that does not attempt to conform to the 'equals' contract, which ensures it will not unintentionally be used for e.g. data structure ordering.

[1] https://github.com/google/auto/blob/master/value/userguide/i...

[2] https://projectlombok.org/features/EqualsAndHashCode

[3] https://blogs.oracle.com/javamagazine/records-come-to-java