So let's back up: what problem are we trying to solve here?
The problem is that the syntax of "with" does not show that with
depends on the deconstructor and the constructor of the record, so the
behavior in case of separate compilation is not clear.
I think the lack of clarity you
Interesting idea. Of the two sides, allowing explicit *constructor*
calls is significantly more practical (`yield` has control flow
consequences understood by the language, and obviously means "yield this
value from the current expression", whereas doing a random pattern match
with `this` as
To the question “does Java need this”, well, of course we don’t *need* it; we
do have try-catch statements. But as Dan points out, the main challenge of
using methods that both return a value and throw exceptions is that we cannot
handle all the results uniformly. And as the JEP points out,
On Tue, 9 Apr 2024 09:32:38 GMT, Adam Sotona wrote:
>> `IllegalArgumentException` thrown by some static factory methods of the
>> following `java.lang.classfile.instruction` interfaces are not documented:
>>
>> - `ArrayLoadInstruction`
>> - `ArrayStoreInstruction`
>> - `BranchInstruction`
>> -
On Wed, 3 Apr 2024 08:48:43 GMT, Adam Sotona wrote:
> Some of the Class-File API options were not mentioned in the package summary
> and one exception mentioned `ClassFile.DeadLabelsOption` javadoc was wrong.
> This patch fixes the javadoc.
>
> Please review.
>
> Thank you,
> Adam
Marked as
On Tue, 9 Apr 2024 13:39:47 GMT, Adam Sotona wrote:
> Class-File API `ClassPrinter` prints many useful info about bootstrap methods
> and invoke dynamic instructions, however bootstrap methods arguments are
> missing.
> This patch fixes bootstrap methods and invoke dynamic instructions
This is super confusing.
It is confusing in part because you are jumping ahead to the one of the
things that I specifically said "we're going to talk about that later",
which is parameterized patterns. (As I've reminded before, jumping
ahead when you are specifically asked not to, means
thout having to have two linguistic ways to write a matcher (with the
attendant "style wars".)
On 4/4/2024 4:18 PM, Guy Steele wrote:
On Apr 4, 2024, at 1:11 PM, Brian Goetz wrote:
There's obviously some more discussion coming about "what is a
pattern", but let me su
I don't think "exhaustiveness" need imply "independence." As an example
from the bytecode API, we have factories for aload_0, aload(0), and
load(INT, 0), all of which produce the same bytecode. It is reasonable
for a "bytecode cursor" to have instance patterns for each of these too,
and for
The examples I had worked out previously were all static patterns, so
this is a good one to work through.
For an instance pattern use, we may or may not put some constraints on
the receiver expression. I have an intuition that some sort of
"effectively constant" constraint is useful, but I
d classes and deconstruction patterns.
On 3/29/2024 5:58 PM, Brian Goetz wrote:
We now come to the long-awaited bikeshed discussion on what member
patterns should look like.
Bikeshed disclaimer for EG:
- This is likely to evoke strong opinions, so please take pains to
be especially
But taking the point of view of such a user, I just don’t see the
need to introduce a new notion of “carrier" to explain the set of
match results (an ordered sequence) from a pattern, just as I
don't see any need to introduce a new notion of “carrier" to
explain the set of
We've had this discussion before.
In the old model, it *is* a two-step process; processors could cache
type and analysis information in the indy call site at capture time
through the Linkage mechanism, and then could use that information at
application time. It's just that in the old model,
ngs _from_ a pattern at runtime.
On 4/3/2024 10:23 AM, fo...@univ-mlv.fr wrote:
----
*From: *"Brian Goetz"
*To: *"Remi Forax"
*Cc: *"amber-spec-experts"
*Sent: *Wednesday,
I would summarize your comments below as: Let's throw the entire model
in the garbage, and replace it with something like Scala's "return an
Optional" instead.
We've been discussing the model for several years; you've been asking
(and waiting patiently) for "when are we going to talk about
The next big pattern matching JEP will be about deconstruction
patterns. (Static and instance patterns will likely come separately.)
Now that we've got the bikeshed painting underway, there are a few other
loose ends here, and one of them is overload selection.
We explored taking the
he temptation to use the imperative
style as a "consolation prize" for the lack of general by-name invocation.
On 3/29/2024 5:58 PM, Brian Goetz wrote:
We now come to the long-awaited bikeshed discussion on what member
patterns should look like.
Bikeshed disclaimer for EG:
- This
We now come to the long-awaited bikeshed discussion on what member
patterns should look like.
Bikeshed disclaimer for EG:
- This is likely to evoke strong opinions, so please take pains to be
especially constructive
- Long reply-to-reply threads should be avoided even more than usual
-
Well, we can start by first examining the methods of the
StringTemplate interface in JDK 22:
I reckon we still need the factories and accessors.
I would like to question the "factories" part of that. As Ron has
pointed out, having string / string template literals be the sole source
of
Here I set forth your three examples with new names that are related
to those already used in the existing preview implementation of
StringTemplate in JDK 21 (and JDK 22—I just checked). I do this not to
suggest that these other names should be used, but only in the hopes
of reducing confusion as
which things were previously processors, but now need API points"
right now -- that's a separate discussion.)
On 3/18/2024 9:38 AM, Brian Goetz wrote:
I think this has been a good discussion, and it looks like we're
starting to see some convergence.
I think we keep trying to exploit
ext
where StringTemplate literal is possible (like it's in the current
preview), then my desire is also satisfied. I see the drawbacks in
every solution, so for now I don't have a strong preference.
With best regards,
Tagir Valeev.
On Tue, Mar 12, 2024 at 6:32 PM Brian Goetz
wrote:
Spl
often require domain-specific validation. For
example, a ST representing a SQL query wants balanced quotes, and might
want to require quotes around embedded expressions.
On 3/8/2024 1:35 PM, Brian Goetz wrote:
Time to check in with where were are with String Templates. We’ve
gone throug
That is how it works in the current version, and this behavior would be
carried forward. Otherwise, it is a form of implicit interpolation,
which goes against the goals of the project.
On 3/13/2024 5:12 PM, Guy Steele wrote:
That reminds me: I would recommend that the instance method
On 3/13/2024 10:48 AM, Archie Cobbs wrote:
I was intrigued by this comment (Maurizio):
> Another, simpler, option we considered was to use some kind of
prefix to mark a string template literal (e.g. make that explicit,
instead of resorting to language wizardry). That works, but has the
Splitting off into a separate thread.
I would like to redirect this discussion from the mechanical challenges
and consequences to the goals and semantics.
If we are considering "String extends StringTemplate", we are making a
semantic statement that a String *is-a* StringTemplate. While I
my vantage point, (c) is
starting to look increasingly unlikely, and I suspect (a) is a better
choice than (b). But I bring this up not to start a project management
discussions, as much as to raise awareness that there are project
management constraints.)
On 3/8/2024 1:35 PM, Brian Goetz wrote:
Time
The overlap between string literals and string template literals is indeed a
tricky one, and bears some review of the options. Obviously string templates
and strings have some things in common (its in the name!), but they are also
different and evaluate to different types. So how “same” or
as
degenerate templates — I’ll let Maurizio give the details, because I’m sure I
will have forgotten one or two.
> On Mar 9, 2024, at 12:45 PM, Guy Steele wrote:
>
>
> Sent from my iPhone
>
>> On Mar 9, 2024, at 12:03 PM, Brian Goetz wrote:
>> . . .
>> At root, t
egards,
Tagir Valeev.
On Fri, Mar 8, 2024 at 7:35 PM Brian Goetz
mailto:brian.go...@oracle.com>> wrote:
Time to check in with where were are with String Templates. We’ve gone through
two rounds of preview, and have received some feedback.
As a reminder, the primary goal of gathering feedbac
Time to check in with where were are with String Templates. We’ve gone through
two rounds of preview, and have received some feedback.
As a reminder, the primary goal of gathering feedback is to learn things about
the design or implementation that we don’t already know. This could be bug
Any assignment statements that occur within the transformation
block have the following constraint: If the left-hand side of the
assignment is an unqualified name, that name must be either (i)
the name of a local component variable, or (ii) the name of a
local variable that
leev wrote:
Hello!
On Fri, Feb 23, 2024 at 4:18 PM Brian Goetz
wrote:
> Simple SQL examples with an "import java.sql.*" and a reference
to a class "Date" to not compile anymore.
Yes, it is unfortunate that there is this collision in java.base.
But t
On 2/26/2024 2:32 AM, fo...@univ-mlv.fr wrote:
Oh, so you do not know why import star/wildcard is considered evil.
The main reason is that an import * is considered as a security
malpractice.
Hyperbole is not helpful here.
(I think we've had this discussion already? Seems eerily familiar.)
I realize that some people think star-imports are a bad idea, and some
style guides recommend against it. But these are preferences, which
make sense in certain situations, and not in others.
This argument goes: since star
On Fri, 5 Jan 2024 15:17:13 GMT, Adam Sotona wrote:
> `java.lang.classfile.CodeBuilder` contains more than 230 API methods.
> Existing ClassFile API use cases proved the concept one big CodeBuilder is
> comfortable. However there are some redundancies, glitches in the naming
> conventions,
- We basically agree that at the use site, we have all the
qualification modes we have with methods { constructor qualified
with package, static member qualified with type, instance member
qualified with receiver } , and possibly, an additional mode of
"instance qualified
(It could also be a default pattern; works the same as default
methods.) The implementation in emptyList always fails. The
implementation in ArrayList might look like:
public __inverse List withElement(T element) {
if (that.size > 0)
_yield
AN easy example is regular expressions. We have a class
j.u.regex.Pattern, which represents a compiled regex. A regular
expression match is a form of pattern match (there's a match
candidate, it is conditional, if it succeeds we extract the capture
groups.) Surely we should expose a
I think your proposal solves the cases where the type you are switching on is
closed (final, sealed) but not if the type is open (non-sealed).
A bold claim! Let's see how this stacks up.
Let's take an example, let suppose I've the following hierarchy
public sealed interface Tree {
The comparison to C# may be syntactically short, but is pretty different
culturally. The block of a C# `with` expression is restricted to
_property assignments_. There, they are aligning the `with` syntax to
the "initialization by properties" that they already had. So this makes
total sense
And as a general remarks, I hope there will be a following JEP about record
instance creation that allows to use the syntax of a transformation block to
initialize a record.
Because as this have been already discussed on several mailing list, if we only
give the derived instance creation
Hello,
I agree until the section 'Recovering static factory arguments', because at
that point, it's the tail waging the dog.
I'm not sure which is tail and which is dog here, but it sure sounds
like you are saying "the entire premise of this exercise is flawed, so
we should throw all this
I was told that the formatting of the earlier version was borked, so
re-sending, hopefully without any formatting this time
# Towards member patterns
Time to check in on where things are in the bigger picture of patterns
as class
members. Note: while this document may have illustrative
# Towards member patterns
Time to check in on where things are in the bigger picture of patterns
as class
members. Note: while this document may have illustrative examples, you
should
not take that as a definitive statement of syntax, and Remi will not be
commenting on the syntax at this
I think we need to separate goals (optimization) from mechanism (syntax).
The optimizations you want to support seem to be exposing more
flattening possibilities when an interface is sealed to a union of
values, and especially one such class. Which is a fine goal.
But if an interface is
Turning to Remi's other comments: these are basically about interaction
of this feature with the two throw-related features that came in in Java
7 -- multi-catch and try-with-resources.
In Java 7 we got multi-catch; you can say
catch (E1|E2 e) { ... }
There are several problems with
On Sat, 16 Dec 2023 15:40:50 GMT, Vladimir Sitnikov
wrote:
>> @vlsi This is a very interesting solution 朗, but it opens a number of
>> questions! 樂 As a start, here are mine:
>> * You propose a new public method (`OutputStream.write(ByteBuffer)`) as part
>> of your solution. We need to
The 'Field.setAccessible' method, which provides a standard API
mechanism for mutating final fields, considers strict finals to be
"non-modifiable", and will not enable reflective writes. (It already
does the same for record fields.)
We discussed this at the EG meeting and I'm still
This seems perfectly sensible to me.
On 12/15/2023 3:22 PM, Dan Smith wrote:
When we last checked in on it, our story for superclasses/interfaces of value
classes was as follows:
In general, classes/interfaces are "unconstrained" and support subclassing by both value
and identity classes.
One of the many reasons in-args should be effectively final.
On 12/14/2023 2:16 AM, John Rose wrote:
P.S. If we ever get in-args into patterns it gets even more wooly,
since those would be little expressions embedded in random places
in the case patterns, and would be evaluated at
Exception cases can be used in all forms of `switch`: expression
and statement
switches, switches that use traditional (colon) or
single-consequence (arrow)
case labels. Exception cases can have guards like any other
pattern case.
I think I would prefer "case
Based on some inspiration from OCaml, and given that the significant
upgrades to switch so far position it to do a lot more than it could
before, we've been exploring a further refinement of switch to
incorporate failure handling as well.
(I realize that this may elicit strong reactions from
I’d like to up-level this discussion a bit from the specific API suggestions,
which are of course meant to be evocative examples.
The examples here are obviously useful; I can imagine use cases for all of
them. I’m a little concerned about adding them as “point” solutions, though,
because I’d
On Wed, 1 Nov 2023 15:39:11 GMT, Brian Goetz wrote:
>> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223:
>>
>>> 221: previousStage.linkedOrConsumed = true;
>>> 222:
>>> 223: previousPreviousStage.nextStag
On Mon, 30 Oct 2023 15:38:35 GMT, Viktor Klang wrote:
> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461)
src/java.base/share/classes/java/util/stream/Gatherer.java line 44:
> 42: *
> 43: * Examples of gathering operations include, but is not limited to:
> 44: * grouping
On Tue, 31 Oct 2023 13:17:51 GMT, Viktor Klang wrote:
>> This is a Draft PR for [JEP-461](https://openjdk.org/jeps/461)
>
> src/java.base/share/classes/java/util/stream/AbstractPipeline.java line 223:
>
>> 221: previousStage.linkedOrConsumed = true;
>> 222:
>> 223:
eed.
*From:* amber-spec-experts on
behalf of Maurizio Cimadamore
*Sent:* 27 October 2023 16:37
*To:* Brian Goetz ;
amber-spec-experts@openjdk.org
*Subject:* Re: Fw: JEP 455: Non-enhanced switch statements
No disagreement here. But
Sure - but this logic is only applied to switch expression featuring
enums AFAIK - switch statements with enums are non-exhaustive (and I
think that will have to stay that way).
Slight correction: switch statements on enum selectors *that don't use
patterns or guards or case null* are
Unfortunately enum is that one case where compatibility dictates that
we can't be exhaustive, which is a little sad... but I think that's
the best we can do?
What we do for enums is do exhaustiveness checking based on the
compile-time state of the world, and generate a synthetic
We have two not-great choices here:
- Treat otherwise-boring switches on long/float/double/boolean (and
their boxes) as legacy primitive switches, omitting the enhanced
exhaustiveness checking;
- Treat switching on float/double/boolean and their boxes as
triggering the enhanced
You may find easier to answer to a direct question:
Since you're the one complaining, the burden is really on you to explain
why it is _not_ a good idea. But I have an answer anyway:
Why do you want the tearability of a nullable value type, which is an
implementation detail, to be
Last year, we stop to use interfaces IdentityObject and ValueObject to specify
value/identity-ness.
LooselyConsistentValue exhibits exactly the same bad behaviors as those
interfaces.
I think if you work through the details, you'll find that it is not the
*exact* same set of behaviors.
t -> z;
}
This obviously doesn't have the problems I outlined with multi-selector,
but it is definitely "weirder". It seeks to capitalize on the strength
reduction of switch relative to an if-else chain, but I'm also not
convinced this one carries its weight.
On 9/27/2023 10:18 AM
[ dropping amber-dev ]
Yes, we've discussed this before. A switch could have multiple selector
values:
switch (a, b)
and cases could be structured similarly:
case (P, Q):
All of this isn't hard. The real question is, does it result in better
or worse code? My sense is that it
I see now I answered a slightly different question :)
We do support case labels for enums in pattern switches, and they
participate in exhaustiveness. But we don't currently support mixing
`case pattern, constant-label` in a single case label. This is waiting
for a more comprehensive
I am pretty sure I saw some spec language for this go by, but Gavin can
fill in the details. But yes, this is desirable because it should be
possible to mix enums and records under a sealed type:
sealed interface X { }
enum E implements X { A; }
record R(int x) implements X { }
On Fri, 8 Sep 2023 10:15:26 GMT, Adam Sotona wrote:
>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>>
>> This patch converts javap to use Classfile API.
>>
>> Please review.
>>
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with
On Tue, 5 Sep 2023 10:59:09 GMT, Adam Sotona wrote:
> This patch performs null checks in to refuse null labels in
> TypeAnnotation.TargetInfo implementations.
>
> Please review.
>
> Thanks,
> Adam
Marked as reviewed by briangoetz (Reviewer).
-
PR Review:
On Wed, 6 Sep 2023 15:03:24 GMT, Adam Sotona wrote:
>> This PR improved Classfile API attributes handling safety by introduction of
>> attribute stability indicator
>> and by extension of UnknownAttributesOption to more general
>> AttributesProcessingOption.
>
> Adam Sotona has updated the
On Thu, 31 Aug 2023 11:09:05 GMT, Adam Sotona wrote:
> Classfile API suppose to throw IllegalArgumentException in situations where
> bytecode offset is out of allowed range. Such situation includes invalid
> offset parsed from a TypeAnnotation as well as from other CodeAttribute
> attributes.
On Fri, 8 Sep 2023 10:27:28 GMT, Adam Sotona wrote:
>> Classfile API `ConstantPool::entryCount` and `ConstantPool::entryByIndex`
>> methods are confusing and unsafe to use without knowledge of constant pool
>> specification.
>> This patch renames `ConstantPool::entryCount` to
The below was received on the valhalla-spec-comments list.
The topic of further relaxing the restrictions on abstract class
supertypes of value classes has been discussed by the EG. While it is
possible that such restrictions could be further relaxed, we are likely
facing diminishing
> On Aug 14, 2023, at 9:04 AM, Tagir Valeev wrote:
>
> Hello!
>
> On Mon, Aug 14, 2023 at 5:44 PM Brian Goetz wrote:
>>
>> So, there are two stable points here: make the where clause part of the
>> pattern, or match it with the case label entirely. Th
rintln("other");
> }
> }
>
> And it looks like there's no way to express the same with an
> arrow-style switch, or even replace adjacent cases with comma (which
> is possible for other cases).
>
> With best regards,
> Tagir Valeev.
>
> On Mon, Aug 14, 20
While we could certainly do this, I think the cost-benefit runs in the wrong
direction here. This sort of thing is better expressed as an if, and that’s
fine. (I think you’ll agree that this example is a little bit contrived.).
> On Aug 14, 2023, at 5:15 AM, Tagir Valeev wrote:
>
> Hello!
I was also wondering about how this will be expressed in MethodHandles
if we don't differentiate Q from L any more It means we don't have
a java.lang.Class for the "Q" flavour so we can't use MethodTypes to
differentiate any more (and that includes losing asType /
castArguments to do
On Fri, 21 Jul 2023 09:37:10 GMT, Adam Sotona wrote:
> 8312491: Update Classfile API snippets and examples
src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 1239:
> 1237: return ldc(BytecodeHelpers.constantEntry(constantPool(),
> value));
> 1238: }
> 1239:
This is a good thought; we split the initialization protocol and its a fair
question to ask whether we can go back to a lump.
In this case, I suspect John is about to say “Please let’s not give the
verifier any more jobs to do.”
> On Jul 13, 2023, at 3:39 AM, Remi Forax wrote:
>
> Hi
“We won’t necessarily keep the Q forever, but it will help us, during
prototyping, to clearly map all of the places where value-ness needs
to be tracked.” I remember thinking, “OK, but we’ll never get rid
of it; it’s too obviously correct.”
Or, if not too obviously correct, too
In case the HTML got mangled by the mailer, I enclose the markdown
original here.
# We don't need no stinkin' Q types
In the last six months, we made a significant breakthrough at the
language/user
level -- to decompose B3 with its value and reference companions, into two
simpler
This mail summarizes some discussions we’ve been having about
eliminating Q descriptors from the VM design. Over time, we’ve been
giving Q fewer and fewer jobs to do, to the point where (perhaps
surprisingly) we can replace the remaining jobs with less intrusive
mechanisms. Additionally, as
On Fri, 30 Jun 2023 00:51:42 GMT, Chen Liang wrote:
>> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which
>> should be implementation details.
>>
>> See
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html
>> for context.
>>
>> This patch
It is irritating that one is a type descriptor and one is a signature,
but we can launder that by observing that both are Utf8Entry.
On 6/29/2023 9:53 AM, Chen Liang wrote:
On Thu, 29 Jun 2023 13:41:17 GMT, Brian Goetz wrote:
`LocalVariable` and `LocalVariableType` includes `writeTo
On Thu, 29 Jun 2023 09:59:08 GMT, Chen Liang wrote:
> `LocalVariable` and `LocalVariableType` includes `writeTo(BufWriter)`, which
> should be implementation details.
>
> See
> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html
> for context.
>
> This patch moves the
On Thu, 29 Jun 2023 09:59:30 GMT, Chen Liang wrote:
> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry,
> FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a
> typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or
>
On Thu, 29 Jun 2023 13:23:51 GMT, Brian Goetz wrote:
>> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry,
>> FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a
>> typeSymbol() API to return the nominal/symbolic des
Please be mindful of the request Viktor made: for feedback on the
approach and the API concepts. It should be pretty clear that low-level
details like "unsupportedCombiner" are many levels down below "approach
and concepts". (And, you know the rule: when you bikeshed on a
low-level detail
Thanks for these comments. To respond indirectly to your point about
parallelization, many of the challenges arise from a tradeoff made in
designing Spliterator, that arises from the desire to be able to extract
parallelism not only from the really easy case (arrays), but also more
complex
Here's how we would define this in Haskell:
data Result t = Succ t | Error Throwable
or maybe (Either-style)
data Result t e = Succ t | Error e
Note that in either, `Error` is still generic in `t`, its just that it
doesn't use `t`, so it doesn't say `t`. Similarly, in the latter,
As a reminder, Leyden will give us a more general tool for "moving stuff
around" at build time than CDS does, and that the current CDS behavior
may well be folded into a set of condensers.
We are trying to find the "perfect" place to put preload information,
but we have (as usual) an
On Thu, 8 Jun 2023 16:37:22 GMT, Adam Sotona wrote:
>> Classfile context object and multi-state options have been discussed at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all
>> affected
Observation: It's dramatic how injecting a tiny amount of shared mutable
state ripples throughout the design.
After thinking about this some more, I think the main problem is that we
are still trying to have the cache be transparent, which means that
Classfile is taking on all the complexity
I still don't understand this point. Why are separate tests sharing a
context at all?
On 6/8/2023 9:26 AM, Adam Sotona wrote:
Unfortunately thread-unsafe context makes sharing of it in tests executed in
parallel a nightmare.
I can fix our Corpus tests and hope the race condition won't raise
On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona wrote:
>> Classfile context object and multi-state options have been discussed at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all
>> affected
On Thu, 8 Jun 2023 13:37:33 GMT, Adam Sotona wrote:
>> Classfile context object and multi-state options have been discussed at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all
>> affected
On Thu, 8 Jun 2023 09:26:10 GMT, Adam Sotona wrote:
>> Classfile context object and multi-state options have been discussed at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all
>> affected
thinking a little bit about STR and FMT, I wonder if we should not introduce
also two other template processors, IN and OUT.
IN is the input template processor, it asks a user for a string on the standard
input
String name = IN."what is your name ?";
It works like input (raw_input) in
On Mon, 5 Jun 2023 14:42:32 GMT, Adam Sotona wrote:
>> Classfile context object and multi-state options have been discussed at
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-May/000321.html
>> This patch implements the proposed changes in Classfile API and fixes all
>> affected
On Mon, 5 Jun 2023 14:38:47 GMT, Adam Sotona wrote:
>> Class-File API actually throws wide variety of exceptions based on the
>> actual situation. Complete error handling code must cover
>> `IndexOutOfBoundsException`, `IllegalStateException` and
>> `IllegalArgumentException`.
>>
>> Based
1 - 100 of 1928 matches
Mail list logo
