From 2021777011 at qq.com Sat Aug 2 12:43:13 2025 From: 2021777011 at qq.com (=?utf-8?B?T2JsaXZSdWluRGV2?=) Date: Sat, 2 Aug 2025 20:43:13 +0800 Subject: [New API] Proposal to Export Selected Internal APIs from java.base to Reduce Duplication Message-ID: As a long-time Java developer, I?ve observed that some internal APIs within java.base provide functionality needed by third-party libraries. However, since these APIs are not exported, libraries only reimplement similar logic, leading to redundant bytecode and increased class-loading overhead. This duplication impacts runtime efficiency and maintenance. I propose exporting some non-sensitive APIs from java.base to a public package, provided they: Preserve JDK integrity/security (e.g., avoid exposing critical internals). Some methods annotated with @IntrinsicCandidate Some APIs I consider it is non-sensitive and exports-valuable: class: java.lang.StringCoding method: java.lang.StringLatin1.inflate(byte[], int, char[], int, int) Expected Benefits: Reduce bytecode duplication ? Smaller footprint and fewer loaded classes. Leverage JDK intrinsics ? Better runtime performance. Simplify library code Some API could moved to a new package(e.g. java.misc) to export to thrid-party libiaries, and we could consider move some new APIs to this package in the next step of development. Feel sorry about my bad English Thank you for considering this proposal! Best regards, OblivRuinDev 2025.08.02. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Thu Aug 7 19:53:21 2025 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 7 Aug 2025 19:53:21 +0000 Subject: String templates In-Reply-To: References: Message-ID: > On 25 Jul 2025, at 20:53, Archie Cobbs wrote: > > On Thu, Jul 24, 2025 at 9:16?PM Rob Ross wrote: > First, I welcome suggestions and feedback on what kind of information is useful to contribute to the topic of string templates in Java. > > There was some preliminary work on this but it got shelved for various reasons. > > I hope Brian will let me know if the following comments are out-of-scope... :) > > My own current thinking on this topic is that instead of trying to define the one true template syntax, Java should take a "pluggable syntax" approach to this problem. > > This would be roughly analogous to annotation processing: The compiler calls out to plug-ins (implementations of SyntaxProcessor say) to evaluate chunks of source code ("templates"). > > The plug-ins would in turn convert the templates into "recipes" for normal evaluation and pass them back to the compiler. Exactly what these "recipes" are is TBD. > > This would look similar to JEP 465 but would be fully agnostic about (a) the literals that define the templates and (b) how they are interpreted. > > Simple example equivalent to JEP 465 but with a different (better?) interpolation syntax: > > import com.example.syntax.SQL; > > public class MyClass { > > public PreparedStatement buildSQL(String name, int age) { > return SQL."SELECT * FROM Person WHERE name = :name AND age = :age"; > } > } > > Key points... > ? The syntax for, and meaning of, "interpolation" in the template, if any, is determined entirely by the SyntaxProcessor. > ? The Java type of the evaluated template expression can be any Java type (ideally, determined dynamically by the SyntaxProcessor) > ? The Literal does not have to be a String, it could be any Java literal. Examples: Currency.'?', Year.2025, etc. > ? The SyntaxProcessor can "access" arbitrary Java expressions, i.e., it can pass them back to the compiler for (eventual) evaluation as part of the "recipe". This facilitates interpolation. > > Another simple example demonstrating a totally different "interpolation" that's more appropriate for an XSL transform: > > import com.example.xml.XSLT; > import javax.xml.transform.*; > > public class MyClass { > > public void xmlSplitFullName(Source input, Result output, String fullNameTag) { > XSLT.""" > > > > > > > > > > > > > > > > > > > > """.transform(input, output); > } > } > > -Archie > > -- > Archie L. Cobbs I think that if we look at the marginal cost and the marginal benefit of this compared to a uniform template argument syntax, the result is unappealing. On the cost side, we?re talking about running arbitrrary third-party code at compile time (including IDE-editing time), which brings some challenges, not to mention that simple syntax highlighting in web interfaces like GitHub simply won?t work. Furthermore, this could only reliably work when the template is a complete document in the target language, which is often not the case. For example, the text `name = ?fullNameTag?` in HTML/XML could be either an element attribute assignment or (part of?) a text node, depending on the context in which it appears. Partial templates are often useful, but if even determining whether something is an argument or or a fragment is programmable, partial templates become effectively impossible. On the benefit side we gain, what? The ability to copy-paste templates from existing templating engines without any processing? ? Ron From archie.cobbs at gmail.com Fri Aug 8 23:22:00 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Fri, 8 Aug 2025 18:22:00 -0500 Subject: String templates In-Reply-To: References: Message-ID: On Thu, Aug 7, 2025 at 2:53?PM Ron Pressler wrote: > On the benefit side we gain, what? The ability to copy-paste templates > from existing templating engines without any processing? It's a good question. Put aside that half-baked idea for adding "literal processors" to the compiler for now - as you note, there are practical issues, but more importantly, discussion of implementation mechanisms is putting the cart before the horse. Instead we first need to ask why such a thing would be helpful. I'm sure other folks have researched this more than me but fwiw I'll throw out a couple of thoughts. First observation: Here's my oversimplified view of Java programming: 1. Writing code that manipulates data being presented to you *already in the language's native format* is "easy". That is, working solely with Java primitive values, Strings, Sets, Maps, Lists, graphs of objects, etc., is easy. You are doing all of your work within the "pure Java world" where the basic operations are well understood, they never fail, an int is always 32 bits, you never run out of memory (i.e., we always just give up if that happens), there are no transactions, no networks that might drop packets or disconnect randomly, no race conditions (except the ones you create yourself), etc. (for me this is the "fun" part of programming, in contrast to #2...). 2. Getting data into and out of this pure Java world is "hard" - or at least, tedious and boring. The pure Java world is the only place you can actually *do anything* in a Java application, so we spend a bunch of time and effort getting data into and out of the pure Java world. In fact, this constitutes the vast majority of the code in most enterprise applications. I'm talking about code for user interfaces, config files, various integrations, database modeling & querying, data (de)serialization, sending/receiving REST API queries, logging, etc. Second observation: Almost all of the non-Java stuff in #2 has corresponding domain-specific models: INI files, HTML/CSS, XML, HTTP/TLS, JSON, SQL, row sets, etc. Because we spend so much time writing Java code to deal with all the non-Java-stuff, it's worth exploring how the language can help make our lives easier. Java's already going in this "data first" direction, with record classes, value classes, the "standard" JSON classes, etc. Those are nice but they are staying very close to the original language. I think it would be OK and not blasphemous for Java to be more flexible and "open minded" at the language lexical level in the service of the "data first" effort also. I'm not sure what that would mean exactly.... but it would be nice to be able to more seamlessly manipulate different data domains directly in Java somehow. Here's a tiny motivating example that's not revolutionary but hopefully gives a taste of the idea (ignore for a moment the fact that kids don't use XML anymore :) Document doc = // read XML document for (Element child : XPATH."$doc/Users/User") { if (XPATH."not($child/favoriteLanguage)") { $child.appendChild(XML."Java"); } } // write out modified XML document The point is we try to accept and embrace the domain models we're working with, instead of effectively saying that everything must always be fully converted to Java before we can work with it. In the example, it appears as if you're working with XPATH and XML directly, which probably more closely matches how you really think about the problem. The mashed-up syntax is actually intuitive. In other words, whenever I'm writing Java code that manipulates an XML document, I'm thinking about the XML document as a data structure, not the programming language - the language being used to do the manipulation is just a means to an end. Why not make it easy to use the most natural language for that particular problem? Side note: those "extension literal" examples are normal Java literals prefixed by NAME DOT but you could support arbitrary literals if we required them to be self-delimiting, at the cost of a more complex parser/extension interface. Example: XML. Of course one could also "untemplate" or deconstruct like we do with patterns: JSON json = // read JSON config String displayName = null; int verbosity = 0; // default quiet JSON.""" { "config": { "displayName": $displayName, "verbosity": $verbosity } }""".deconstruct(); assert displayName != null; if (verbosity > 0) System.out.println("Using display name \"" + displayName + "\""); There are limits to what we could do - in the end, everything would still really be Java under the covers - and this would definitely be major compiler surgery. But I think it's at least worth the thought experiment. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sat Aug 9 15:00:37 2025 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 9 Aug 2025 15:00:37 +0000 Subject: [External] : Re: String templates In-Reply-To: References: Message-ID: <5067C8FA-07CC-4D3A-9B7B-2EFF76CE2488@oracle.com> > On 9 Aug 2025, at 00:22, Archie Cobbs wrote: > > > Because we spend so much time writing Java code to deal with all the non-Java-stuff, it's worth exploring how the language can help make our lives easier. Sure. > > Java's already going in this "data first" direction, with record classes, value classes, the "standard" JSON classes, etc. Those are nice but they are staying very close to the original language. I think it would be OK and not blasphemous for Java to be more flexible and "open minded" at the language lexical level in the service of the "data first" effort also. Right. > > Here's a tiny motivating example that's not revolutionary but hopefully gives a taste of the idea (ignore for a moment the fact that kids don't use XML anymore :) > > Document doc = // read XML document > for (Element child : XPATH."$doc/Users/User") { > if (XPATH."not($child/favoriteLanguage)") { > $child.appendChild(XML."Java"); > } > } > // write out modified XML document > > The point is we try to accept and embrace the domain models we're working with, instead of effectively saying that everything must always be fully converted to Java before we can work with it. In the example, it appears as if you're working with XPATH and XML directly, which probably more closely matches how you really think about the problem. The mashed-up syntax is actually intuitive. In other words, whenever I'm writing Java code that manipulates an XML document, I'm thinking about the XML document as a data structure, not the programming language - the language being used to do the manipulation is just a means to an end. Why not make it easy to use the most natural language for that particular problem? I?m entirely with you, but I don?t see why that means that the *syntax for a template argument* needs to be different for every hosted language. Templates are an interface between Java and a hosted language, where the fragments are in the hosted language while the arguments are in Java. Since the arguments are in Java, why can?t their escape - i.e. the transition from the hosted language back to Java - be universal (i.e. `\{arg}`)? Just note that not every useful template/fragment in a hosted language is interpretable in the hosted language as-is. E.g. the token 3 in Java could be an integer value, part of a Java string, or part of a Java comment. The processor of the host language cannot always interpret some partial template, or even determine if it?s valid or not, until the full context is available. That?s one of the core points of our design explorations. ? Ron From archie.cobbs at gmail.com Sat Aug 9 17:43:43 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Sat, 9 Aug 2025 12:43:43 -0500 Subject: [External] : Re: String templates In-Reply-To: <5067C8FA-07CC-4D3A-9B7B-2EFF76CE2488@oracle.com> References: <5067C8FA-07CC-4D3A-9B7B-2EFF76CE2488@oracle.com> Message-ID: On Sat, Aug 9, 2025 at 10:00?AM Ron Pressler wrote: > I?m entirely with you, but I don?t see why that means that the *syntax for > a template argument* needs to be different for every hosted language. > Templates are an interface between Java and a hosted language, where the > fragments are in the hosted language while the arguments are in Java. Since > the arguments are in Java, why can?t their escape - i.e. the transition > from the hosted language back to Java - be universal (i.e. `\{arg}`)? > The only answer to that question I can think of is that many languages already have a lexical notion of a parameter or variable and don't need a new one. For example, it would be cleaner to write XPATH."($param/foo[@myattr])" instead of XPATH."\{param}/foo[@myattr]". There's no reason you couldn't support both of course, but "native parameters" would come with a big new cost - the compiler would have to decode them at parse time, and that means supporting lexical extension plugins of some kind. Which leads me to back up and ask this question. If T is the other (non-Java language), do we include T templates using (a) Java string literals (or string literals plus \{foo} placeholders), or (b) some kind of lexical escape/plugin mechanism that allows T to define whatever syntax it wants? Option (b) is more complicated compiler-wise but provides a cleaner result. You could reference variables using T's native format (as described above) and also not have to use text blocks to avoid backslash hell, e.g., you could write: JSON.{ "a": 123, "b": false } Would option (b) be worth the extra trouble? It would have complexity on par with annotation processing, which we found worth doing, so I feel like it's not entirely crazy to ask the question. However, I'm guessing it's probably not worth the extra trouble unless this would open up some cool new capabilities that we haven't thought of yet. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at upliftinglemma.net Sat Aug 9 19:49:42 2025 From: chris at upliftinglemma.net (Chris Bouchard) Date: Sat, 9 Aug 2025 15:49:42 -0400 Subject: [External] : Re: String templates In-Reply-To: References: <5067C8FA-07CC-4D3A-9B7B-2EFF76CE2488@oracle.com> Message-ID: On Sat, Aug 9, 2025, 13:45 Archie Cobbs wrote: The only answer to that question I can think of is that many languages > already have a lexical notion of a parameter or variable and don't need a > new one. > > For example, it would be cleaner to write XPATH."($param/foo[@myattr])" instead > of XPATH."\{param}/foo[@myattr]". > The problem, in my opinion, is that the only common denominator with templates is that we're writing Java. How does a code reviewer for this snippet know that XPath uses $ to introduce variable references? What about the @? Is that one too? From the reviewer's point of view, there's no syntactic indication that there are *any* variable references here, because the only syntax we can assume they know is Java syntax. To truly emulate embedded language roles for variable references, each template processor would need to define its own bespoke, unpredictable, potentially context-sensitive rules for variable references. Consider a language like Bash, where an unbraced variable reference ends at the first character that is not valid in a variable name. I think my expectation for templates would be that, as long as the reviewer knows the *template system*?not the individual template processors, but the syntax for using templates?they should be able to answer those questions. It feels untenable to force reviewers to research individual template processors for questions as basic and security-sensitive as, "Is this template capturing PII?" But also, you could imagine a language template like final int x = 42; var e = JAVASCRIPT."() => { return x; }"; that creates a JSExpression object, which can be passed to a hosted JavaScript runtime for evaluation. In JavaScript, that x is referencing a variable that has not been declared lexically, so it could capture a variable in the outer scope. Does that template capture the Java variable x declared above? Or would it use the global x variable in my hosted JavaScript runtime? Neither option is obviously correct, and both are limiting. If that syntax does capture the x from Java, how do I disable that so I can reference the JavaScript global? That's maybe not obviously useful for x, but what about variables like String or Function (since those are variables in JavaScript). And if that syntax doesn't capture the x from Java, then how would I express that when there's no JavaScript syntax for "reference this variable outside the runtime." Both options require the template implementation to invent invent an escape syntax that JavaScript doesn't have. This isn't a problem just for JavaScript?how many languages with variable references also have a syntax for escaping that reference to some unknown outer host score? So why not just use a standard Java escape syntax instead? And finally, using in-language syntax for variable references precludes embedding anything more interesting that a variable. For example, compare JAVASCRIPT."{ a: \{obj.x}, b: \{obj.y}, c: \{obj.z} }" with var x = obj.x; var y = obj.y; var z = obj.z; JAVASCRIPT."{ a: x, b: y, c: z }" The latter is more verbose and repetitive, and introduces an extra layer of indirection to know what's being used in the expression?all to avoid typing \{}. I'll say, I can see the appeal of language-specific sub-syntaxes from the point of view of an author who is familiar with each template processor they're using. But I don't feel like they're a big enough win for the cost in understanding for everyone else. Chris Bouchard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sat Aug 9 19:55:26 2025 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 9 Aug 2025 19:55:26 +0000 Subject: [External] : Re: String templates In-Reply-To: References: <5067C8FA-07CC-4D3A-9B7B-2EFF76CE2488@oracle.com> Message-ID: <04D3E81F-C778-4E2C-B535-A4346E877BCC@oracle.com> > On 9 Aug 2025, at 18:43, Archie Cobbs wrote: > > On Sat, Aug 9, 2025 at 10:00?AM Ron Pressler wrote: > I?m entirely with you, but I don?t see why that means that the *syntax for a template argument* needs to be different for every hosted language. Templates are an interface between Java and a hosted language, where the fragments are in the hosted language while the arguments are in Java. Since the arguments are in Java, why can?t their escape - i.e. the transition from the hosted language back to Java - be universal (i.e. `\{arg}`)? > > The only answer to that question I can think of is that many languages already have a lexical notion of a parameter or variable and don't need a new one. > > For example, it would be cleaner to write XPATH."($param/foo[@myattr])" instead of XPATH."\{param}/foo[@myattr]". > > There's no reason you couldn't support both of course, but "native parameters" would come with a big new cost - the compiler would have to decode them at parse time, and that means supporting lexical extension plugins of some kind. > > Which leads me to back up and ask this question. If T is the other (non-Java language), do we include T templates using (a) Java string literals (or string literals plus \{foo} placeholders), or (b) some kind of lexical escape/plugin mechanism that allows T to define whatever syntax it wants? > > Option (b) is more complicated compiler-wise but provides a cleaner result. You could reference variables using T's native format (as described above) and also not have to use text blocks to avoid backslash hell, e.g., you could write: JSON.{ "a": 123, "b": false } ? and this, again, assumes that the template carries enough context for T to even decide whether the expression is valid syntax or not, which isn?t always the case (unless the ?language identifier? also explicitly includes the relevant context kind, which is both complicated and adds burden on the programmer. From rotanolexandr842 at gmail.com Sat Aug 9 20:23:44 2025 From: rotanolexandr842 at gmail.com (Olexandr Rotan) Date: Sat, 9 Aug 2025 23:23:44 +0300 Subject: [External] : Re: String templates In-Reply-To: <04D3E81F-C778-4E2C-B535-A4346E877BCC@oracle.com> References: <5067C8FA-07CC-4D3A-9B7B-2EFF76CE2488@oracle.com> <04D3E81F-C778-4E2C-B535-A4346E877BCC@oracle.com> Message-ID: > > ? and this, again, assumes that the template carries enough context for T > to even decide whether the expression is valid syntax or not, which isn?t > always the case (unless the ?language identifier? also explicitly includes > the relevant context kind, which is both complicated and adds burden on the > programmer. Regarding the context part, I think that Graal polyglot is a good example of how language interoperations are currently most commonly implemented. Basically, most of the time some kind of context is created, and the globals are defined before evaluation. Same pattern with, for example, Jexl and Jxlt for templates and expression evaluation. The very naive implementation may be to provide some opt-in mechanism for the template processor to capture *values* from the outer scope, similarly to what lambdas and inner classes do. However, this would require template processors to be allowed to be instances, and not just classes (which, I assume was allowed in the original proposal), and that brings us to the point of being unable to validate syntax at the compile time, because where there are instances instead of classes, there is polymorphism. Say we have a "parser" processor instance, which can either parse XML or JSON, depending on the implementation of the type. This lack of information forces syntax validation to be deferred to the runtime instead of compile-time. The takeaway here is that compile-time validation is only an option for static processors, which largely narrows the range of use cases for them. On the side note, I fear that custom syntax validation at compile time may dramatically increase build time, and noone wants Java to compile slower the C++, i guess Regards On Sat, Aug 9, 2025 at 10:55?PM Ron Pressler wrote: > > > > On 9 Aug 2025, at 18:43, Archie Cobbs wrote: > > > > On Sat, Aug 9, 2025 at 10:00?AM Ron Pressler > wrote: > > I?m entirely with you, but I don?t see why that means that the *syntax > for a template argument* needs to be different for every hosted language. > Templates are an interface between Java and a hosted language, where the > fragments are in the hosted language while the arguments are in Java. Since > the arguments are in Java, why can?t their escape - i.e. the transition > from the hosted language back to Java - be universal (i.e. `\{arg}`)? > > > > The only answer to that question I can think of is that many languages > already have a lexical notion of a parameter or variable and don't need a > new one. > > > > For example, it would be cleaner to write XPATH."($param/foo[@myattr])" > instead of XPATH."\{param}/foo[@myattr]". > > > > There's no reason you couldn't support both of course, but "native > parameters" would come with a big new cost - the compiler would have to > decode them at parse time, and that means supporting lexical extension > plugins of some kind. > > > > Which leads me to back up and ask this question. If T is the other > (non-Java language), do we include T templates using (a) Java string > literals (or string literals plus \{foo} placeholders), or (b) some kind of > lexical escape/plugin mechanism that allows T to define whatever syntax it > wants? > > > > Option (b) is more complicated compiler-wise but provides a cleaner > result. You could reference variables using T's native format (as described > above) and also not have to use text blocks to avoid backslash hell, e.g., > you could write: JSON.{ "a": 123, "b": false } > > ? and this, again, assumes that the template carries enough context for T > to even decide whether the expression is valid syntax or not, which isn?t > always the case (unless the ?language identifier? also explicitly includes > the relevant context kind, which is both complicated and adds burden on the > programmer. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From archie.cobbs at gmail.com Mon Aug 11 16:35:14 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Mon, 11 Aug 2025 11:35:14 -0500 Subject: [External] : Re: String templates In-Reply-To: References: <5067C8FA-07CC-4D3A-9B7B-2EFF76CE2488@oracle.com> Message-ID: On Sat, Aug 9, 2025 at 2:49?PM Chris Bouchard wrote: > On Sat, Aug 9, 2025, 13:45 Archie Cobbs wrote: > > The only answer to that question I can think of is that many languages >> already have a lexical notion of a parameter or variable and don't need a >> new one. >> >> For example, it would be cleaner to write XPATH."($param/foo[@myattr])" instead >> of XPATH."\{param}/foo[@myattr]". >> > > The problem, in my opinion, is that the only common denominator with > templates is that we're writing Java. How does a code reviewer for this > snippet know that XPath uses $ to introduce variable references? > I would assume that anyone reviewing some code that has bits of language A embedded within larger bits of language B would be expect to understand both A and B...? > > Both options require the template implementation to invent invent an > escape syntax that JavaScript doesn't have. This isn't a problem just for > JavaScript?how many languages with variable references also have a syntax > for escaping that reference to some unknown outer host score? So why not > just use a standard Java escape syntax instead? > > And finally, using in-language syntax for variable references precludes > embedding anything more interesting that a variable. For example, compare > > JAVASCRIPT."{ a: \{obj.x}, b: \{obj.y}, c: \{obj.z} }" > > with > > var x = obj.x; > var y = obj.y; > var z = obj.z; > JAVASCRIPT."{ a: x, b: y, c: z }" > > The latter is more verbose and repetitive, and introduces an extra layer > of indirection to know what's being used in the expression?all to avoid > typing \{}. > > I'll say, I can see the appeal of language-specific sub-syntaxes from the > point of view of an author who is familiar with each template processor > they're using. But I don't feel like they're a big enough win for the cost > in understanding for everyone else. > Ok you've convinced me... and also made me realize that is really part of a larger problem, which is that template processors are (in general) only ever going to support a limited set of lexical substitution locations. For example, this most likely wouldn't work: String string = "I say \"Hello\"\nTo the world\n"; var script = BASH.""" bash -c "echo `echo \{string}`" """; because: is the template processor really going to understand (a) bash's nested quoting rules, and (b) how echo(1) parses its command line argument(s), and therefore by implication every other Unix command you could possibly put in a bash script? So a bash script template processor is likely only going to support the most basic substitutions, like VAR=\{string}. In other words there is a language nesting complexity blowup that will limit the substitution flexibility of many templates (maybe this was already obvious to everyone but me). For another "nesting" example, one might think the following would be reasonable to do: String oldTagName = "foo-bar"; String newTagName = "hah-hah"; var xsl = XML.""" """; But is the XML template processor really going to be smart enough to recognize this as an XSLT transform with an embedded XPath expression and know that the substitution rules for oldTagName and newTagName are different? Not likely. So to wrap up: my ideas of "language-native" parameterization and template syntax don't really add much - because templates are already limited in a more fundamental way. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: