• Some friends shared this article from Uwe Friedrichsen, tilted back to the future, that talks about this feeling of “déjà-vu”, this impression that in IT we keep on reinventing the wheel. With references to mainframes, Uwe compared CICS to Lambda function scheduling, JCL to step functions, mainframe software development environments to the trendy platform engineering. There are two things I like about this article. First of all, it rings a bell with me, as we’ve seen the pendulum swing as we keep reinventing some patterns or rediscovering certain best practices, sometimes favoring an approach one day, and coming back to another approach the next day. But secondly, Uwe referenced Gunter Dueck who talked about spirals rather than a pendulum. I’ve had that same analogy in mind for years: rather than swinging on one side to the next and back, I always had this impression that we’re circling and spiraling, but each time, even when passing on the same side, we’ve learned something along the way, and we’re getting closer to an optimum, with a slightly different view angle, and hopefully with a better view and more modern practices. Last week at FooConf #2 in Helsinki, I was just talking with my friend Venkat Subramaniam about this spiral visualisation, and I’m glad to see I’m not the only one thinking that IT is spiraling rather than swinging like a pendulum.

  Read more...

• Stop Using char in Java. And Code Points
  It’s a can of worms, when you start messing with chars, code points, and you’re likely going to get it wrong in the end. As much as possible, stay away from chars and code points, and instead, use as much as possible the String methods like indexOf() / substring(), and some regex when you really need to find grapheme clusters.

• Paul King shared his presentations on Why use Groovy in 2023 and an update on the Groovy 5 roadmapIt’s interesting to see how and where Groovy goes beyond what is offered by Java, sometimes thanks to its dynamic nature, sometimes because of its compile-time transformation capabilities. When Groovy adopts the latest Java features, there’s always a twist to make things even groovier in Groovy!

  Read more...

In the literature, you’ll easily find information on how to rate-limit your API. I even talked about Web API rate limitation years ago at a conference, covering the usage of HTTP headers like X-RateLimit-*.

Rate limiting is important to help your service cope with too much load, or also to implement a tiered pricing scheme (the more you pay, the more requests you’re allowed to make in a certain amount of time). There are useful libraries like Resilience4j that you can configure for Micronaut web controllers, or Bucket4j for your Spring controllers.

As I started my journey with Generative AI and Large Language Models, I’ve been overwhelmed with the omnipresence of Python. Tons of resources are available with Python front and center. However, I’m a Java developer (with a penchant for Apache Groovy, of course). So what is there for me to create cool new Generative AI projects?

When I built my first experiment with the PaLM API, using the integration within the Google Cloud’s Vertex AI offering, I called the available REST API, from my Micronaut application. I used Micronaut’s built-in mechanism to marshal / unmarshal the REST API constructs to proper classes. Pretty straightfoward.

Last week, I wrote about how to get started with the PaLM API in the Java ecosystem, and particularly, how to overcome the lack of Java client libraries (at least for now) for the PaLM API, and how to properly authenticate. However, what I didn’t explain was what I was building! Let’s fix that today, by telling you a story, a kid story! Yes, I was using the trendy Generative AI approach to generate bedtime stories for kids.

Large Language Models (LLMs for short) are taking the world by storm, and things like ChatGPT have become very popular and used by millions of users daily. Google came up with its own chatbot called Bard, which is powered by its ground-breaking PaLM 2 model and API. You can also find and use the PaLM API from withing Google Cloud as well (as part of Vertex AI Generative AI products) and thus create your own applications based on that API. However, if you look at the documentation, you’ll only find Python tutorials or notebooks, or also explanations on how to make cURL calls to the API. But since I’m a Java (and Groovy) developer at heart, I was interested in seeing how to do this from the Java world.

In this article, let’s revisit the topic of deploying Java apps on Cloud Run. In particular, I’ll deploy a Micronaut app, written with Java 17, and built with Gradle.

With a custom Dockerfile

On Cloud Run, you deploy containerised applications, so you have to decide the way you want to build a container for your application. In a previous article, I showed an example of using your own Dockerfile, which would look as follows with an OpenJDK 17, and enabling preview features of the language:

Time to spill the beans and show the gems, to our friendly snakes and elephants: we’ve got some great news for Java, Ruby, Python and PHP serverless developers today. Google App Engine and Cloud Functions are adding new modern runtimes, allowing you to update to the major version release trains of those programming languages.

In short, here’s what’s new:

• Access to App Engine legacy bundled services for Java 11/17, Python 3 and Go 1.12+ runtimes, is Generally Available

  Read more...

One year after Google App Engine was released in 2008, Java became the second language runtime available on the platform. Java developers were able to deploy and scale their servlet-based web applications easily, without worrying about infrastructure management. Not only Java was able to run then, but alternative JVM languages, like Apache Groovy, and Kotlin are also part of the game. Fast forward to today, we’re pleased to announce that the Java Runtime for App Engine is now available as open source, in the GoogleCloudPlatform/appengine-java-standard repository on Github.

As I was working with my colleague Sara Ford on testing the Cloud Functions runtimes for the upcoming “second generation” of the product, rebased on the Cloud Run platform, I wrote a few simple functions for the Java runtime. In one of those Java functions, I wanted to use Google Cloud Storage, to download a file from a bucket. I took a look at the existing sample to download an object:

Storage storage = StorageOptions.newBuilder()
    .setProjectId(projectId)
    .build()
    .getService();

Blob blob = storage.get(BlobId.of(bucketName, objectName));
blob.downloadTo(Paths.get(destFilePath));

I know the name of the bucket, the name of the file, I’m going to store the file in the local file system. So I have all the information needed… except the project ID within which I deployed my Java cloud function. So how do I get the project ID, in Java, inside the Cloud Functions environment?