Skip to main content

APEXlang is here

A

APEX 26.1 ships tomorrow. After 2 years of massive team effort, we have Oracle APEX Special Update office hours scheduled for Thursday May 14th, 16:00 CEST, and the marquee feature is finally coming out of the oven. Six new icons!

The feature is APEXlang, an open application specification language, and it's the biggest change to APEX since its introduction in 2004.


APEXlang in one paragraph

APEXlang is a new export/import format for APEX apps. Instead of a single ".sql" script with environment-specific numeric IDs, you get a zipped package of ".apx" files (one per page, one per shared component, one at app level) plus native ".sql", ".css", ".png", ".js" files living at proper paths. It is something like ".yaml" files, but on steroids and editable. Human readable, diffable, mergeable, Git-friendly. Same IDs across environments (static and non-numeric). The classic SQL script export isn't going anywhere, it stays supported. APEXlang is the parallel track designed from day one as a generation target for LLMs like Claude and Codex.


SQL export vs APEXlang, side by side

This is from Mike's April 16th post, compressed:

  • File format – SQL: one .sql file. APEXlang: zipped package of .apx + native asset files.
  • IDs – SQL: environment-specific GUIDs. APEXlang: same on every environment, components referenced with @.
  • Editing – SQL: not supported, risks metadata corruption. APEXlang: fully supported with validation.
  • Diff – SQL: false diffs everywhere, hard to read. APEXlang: only real differences show, clean terminology.
  • Merge – SQL: virtually impossible. APEXlang: easy, fully supported.
  • AI generation – SQL: not documented, not recommended. APEXlang: fully documented, fully supported.

Same app, two ways out the door.


Intent, not code

It is an abstract layer. Mike's framing is that you generate "intent", not code. You write requirements in Markdown, describe your data model, annotate it, then let an LLM translate all that into APEXlang. The APEX IDE stays, nobody is taking the builder away, but a second workflow opens up. Spec-driven generation from VS Code, with APEX as the target.

It won't be 100% generation. Mike himself says early results will be "ok" and will improve as the community shares skills, prompts, and examples. But bulk operations like "rename column ENAME to EMPLOYEE_NAME across all reports, forms, LOVs, and install scripts" collapse into a single prompt. That alone is worth getting ready for.

The language was deliberately designed to be validatable (so the LLM gets compile-time feedback and can self-correct), abstracted (capture intent, not implementation), and LLM-agnostic (any model that can produce valid syntax can drive it). And it has a public grammar, so the models will keep getting better at it as the community trains them.


The four-point prep list

From Mike's April 9th post:

  1. Define your project, write requirements in Markdown
  2. Upgrade to Oracle Database 26ai (23.26 minimum for annotations and SQL Assertions)
  3. Annotate your tables and columns
  4. Start using Git and VS Code with an AI coding assistant (Claude Code, Codex, ...)

The first two are obvious. The fourth one most of us are doing already. Step 3 is the interesting one because it's genuinely new work, and that's where the next section goes.


Annotations in 26ai

Annotations are a 23ai feature (backported to 19.28) that attach structured name-value metadata to database objects (tables, columns, views, indexes, domains). Think of them as comments with structure. Unlike "COMMENT ON COLUMN", you can attach multiple name-value pairs per object, and you can query them from the data dictionary.

The six annotation names APEXlang generation expects:

  • display_label – how the column or table should be labeled in the UI.
  • format_mask – how to format the value. Dates, numbers, currencies.
  • primary_display_column – for a given table, which column is "the name" to show in LOVs, pickers, breadcrumbs. Table level only.
  • search_facet – flags columns that should appear as facets in a faceted search page.
  • semantic_type – a typed hint for what the column really is (email, phone, iso.country_code, identifier, url, currency.amount). Lets the LLM pick the right APEX item type.
  • ai_context – free-form description for the LLM. This is where you explain what the column means in the context of your business.

The first three replace guesswork the rest of us do manually today. The last three are purely for AI, they give the model enough context to make sensible generation choices.

Quick syntax for an existing column:

alter table customers modify country_code
    annotation ai_context 'ISO two-letter country codes';

And to see what's attached anywhere in your schema:

select  object_name, column_name, annotation_name, annotation_value
from    user_annotations_usage
order by object_name, column_name, annotation_name;

These six are not Oracle-reserved names. Annotation names are free text, so APEX 26.1 just adopts this convention. Your own tooling can add more.


Two things to pair with annotations

Move business logic into PL/SQL APIs, not forms on tables. When all logic lives in the app, APEXlang generation has less to work with, and so do your future MCP, REST, or Java clients. A clean PL/SQL API layer means one source of truth for validations, and the LLM can read it and generate UI on top instead of guessing. Same logic for every caller. I am talking about this for years, now you are getting extra motivation to finally do that.

Use the new Describe Tables utility. APEX 26.1 ships a "SQL Workshop > Utilities > Describe Tables" page that produces a token-friendly Markdown dump of selected tables (comments, annotations, constraints, datatypes). You can pull the same thing programmatically with "APEX_DB_DICTIONARY.GET_TABLE_INFO". Faster than data dictionary queries, smaller for the LLM, and you only feed the model the tables it needs for the current task. Sounds cool, right?


Why do this now

Your Claude Code or Codex session can read the annotations and stop guessing what "CUST_SEG_CD" means. Once APEX 26.1 ships, an annotated schema will generate noticeably better apps than a bare one, same query, much better defaults. Doing this manually is a no-go.

Keep an eye on the Oracle repo for new skills.


What to do this week

Pick one table in a dev schema you own, a customer or product table works well. Add the six annotations by hand. Query "user_annotations_usage" to confirm they are there. Then ask your AI assistant a question about that table and compare the answer to what it used to give you. The difference is immediate once the model has semantic context instead of column names.

If this was useful, pass it to a colleague who is still waiting for 26.1.

See you on the office hours tomorrow. The "soon" has arrived.


Tags:

Comments

Post a Comment