update blob trigger docs with java blob sdk preview details

Author: ahmedmuhsin

articles/azure-functions/functions-bindings-storage-blob-trigger.md

@@ -577,6 +577,111 @@ Because the blob trigger uses a queue internally, the maximum number of concurre
 
 Limits apply separately to each function that uses a blob trigger.
 
+::: zone pivot="programming-language-java"
+## Preview SDK-types for Blob Storage
+
+### What this preview delivers
+
+Until now a Blob-triggered Java function could receive only raw bytes or strings.
+The new **SDK-type binding** lets your function accept a *real* Azure Storage SDK client – either `BlobClient` or `BlobContainerClient`.
+
+* Use every Storage API (leases, tiers, snapshots, …) directly.
+* Stream data straight from Storage – no 100 MB blob-size ceiling, no extra memory copies.
+* One client instance is cached and reused across invocations for maximum throughput.
+
+### Why you might switch
+
+| Classic binding (`byte[]` / `String`)        | SDK-type binding (`BlobClient`, `BlobContainerClient`)       |
+| -------------------------------------------- | ------------------------------------------------------------ |
+| Host downloads blob, sends it to the worker. | Worker streams from Storage itself – lower latency & memory. |
+| 100 MB size limit.                           | No hard limit; streams as big as Storage allows.             |
+| Only read/write bytes.                       | Full SDK surface: metadata, ACLs, legal hold, etc.           |
+
+### What you need
+
+* Turn the feature on by setting `JAVA_ENABLE_SDK_TYPES` to `"true"` in your
+  app's settings.
+* **azure-functions-maven-plugin** (or Gradle plug-in) ≥ **1.38.0** – detects SDK-type parameters during build and adds the flag that activates the middleware.
+* Your function app must reference:
+
+  * `azure-storage-blob` (always)
+  * `azure-identity` (only if you plan to use Managed Identity)
+
+> The worker creates clients via reflection, so it relies on whatever Storage/Identity libraries you ship with the function.
+
+### Authoring – it looks just like a normal binding
+
+```java
+@FunctionName("processBlob")
+public void run(
+        @BlobTrigger(
+                name = "content",
+                path = "images/{name}",
+                connection = "MyStorage") BlobClient blob,
+        @BindingName("name") String file,
+        ExecutionContext ctx)
+{
+    ctx.getLogger().info("Size = " + blob.getProperties().getBlobSize());
+}
+```
+
+```java
+@FunctionName("containerOps")
+public void run(
+        @BlobTrigger(
+                name = "content",
+                path = "images/{name}",
+                connection = "MyStorage") BlobContainerClient container,
+        ExecutionContext ctx)
+{
+    container.listBlobs()
+            .forEach(b -> ctx.getLogger().info(b.getName()));
+}
+```
+
+* `dataType` on **@BlobTrigger** is **ignored** when you bind to an SDK-type.
+* `connection` can be a connection string **or** an identity-based prefix – both work with SDK-types.
+
+### What happens under the hood (in one minute)
+
+1. **Build:** the Maven plug-in scans your methods. If it sees `BlobClient` or `BlobContainerClient` it writes `"supportsDeferredBinding": true` into `function.json`.
+2. **Startup:** the worker notices the flag and inserts **SdkTypeMiddleware** before your function executes.
+3. **Invocation:** for each SDK-typed parameter the middleware
+
+   * reads the binding metadata,
+   * looks in the **WorkerObjectCache**; if no entry exists it uses reflection to construct the client,
+   * injects the client into the argument list.
+
+The cache key is derived from container name + blob name (or just container, for `BlobContainerClient`) plus the connection prefix. Thus identical invocations reuse one client; distinct blobs get their own.
+
+
+### Managed Identity
+
+SDK-types honor the same identity-based connection settings you already use with classic bindings.
+Simply point `connection` to an MI prefix and add `azure-identity` to your function’s dependencies – the worker will build `DefaultAzureCredential` reflectively.
+(No additional steps are required in the worker.)
+
+### Troubleshooting
+
+| Exception                  | Meaning                                                                                                          |
+| -------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| `SdkAnalysisException`     | Build plug-in couldn’t create metadata (duplicate SDK-types in one signature, unsupported parameter type, etc.). |
+| `SdkRegistryException`     | Runtime doesn’t recognize the stored FQCN – probably mismatched library versions.                                |
+| `SdkHydrationException`    | Middleware failed to build the SDK client (missing env-vars, reflection error, credential failure).              |
+| `SdkTypeCreationException` | Factory couldn’t turn metadata into the final SDK-type (usually casting issues).                                 |
+
+Check the inner message for the exact cause; most issues are mis-spelled environment variables or missing dependencies.
+
+### Future work
+
+This is the **first** SDK-type preview. We plan to:
+
+* Add more Storage client types, then branch into Cosmos DB, Event Hubs, etc.
+* Promote the feature to General Availability once telemetry shows it’s solid.
+
+Give it a try in a test function app and tell us how much faster your blob processing becomes!
+
+
 ## host.json properties
 
 The [host.json](functions-host-json.md#blobs) file contains settings that control blob trigger behavior. See the [host.json settings](functions-bindings-storage-blob.md#hostjson-settings) section for details regarding available settings.