Without commenting on the merits of the proposal, let me point out that asking
for a sponsor at this point is skipping many important steps.
I would recommend you focus first on *building consensus* that (a) there is a
problem, (b) you have identified the correct problem, (c) it is a problem t
On 6/23/2020 2:08 PM, Gilles Duboscq wrote:
In 8232806, a system property was introduce to disable eager initialization of
the classes generated by the InnerClassLambdaMetafactory
(`jdk.internal.lambda.disableEagerInitialization`).
However, when `disableEagerInitialization` is true, even fo
Consider a ClassValue for this, if there is not an obvious bit to be
repurposed somewhere.
On 6/23/2020 12:30 PM, Chris Hegarty wrote:
I think it is worth considering caching the record-ness state of a j.l.Class,
as I’m sure it will be widely used in third-party serialization libraries, as
we
On 6/24/2020 7:32 PM, Remi Forax wrote:
I don't really like the name "mapMulti", because flatMap can also be called
mapMulti.
Public service announcement: remember just how frustrating it is for
Patrick to have put in all this work and get only comments like "I don't
like the name."
If
On 7/24/2020 7:48 AM, Volker Simonis wrote:
I think it's reasonable to ask if the JDK
really needs to support this complexity.
I can't see much complexity here.
Then I think we should start there. Until you can see the complexity
here that is obvious to Alan, Lance, myself, and others, t
So from your (and Alan's and Lance's) point of view does it still make
sense to create a JEP for this enhancement and have a broader
discussion about its usefulness on the "discuss" list? Or is your
rejection definitive, no matter what the outcome of such a discussion
will be?
I think it's
Should this patch be a workaround to existing releases rather than
the main line? As Brian mentions, lambda proxy class may become
inline class in valhalla repo (Roger has a patch already). The
earlier fixing those programs the better.
Indeed if we know this is landing in this cycle i
Minor nit:
Appendable foo(Appendable bar)
should be
A foo(A bar)
That way, if you say
hex.formatHex(aStringBuilder, bytes)
.foo()
where foo() is a method on StringBuilder but not on Appendable, it will
still work as expected.
On 9/28/2020 11:32 AM, Roger Riggs wrote:
A
This change introduces a new terminal operation on Stream. This looks like a
convenience method for Stream.collect(Collectors.toList()) or
Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
method directly on Stream enables it to do what can't easily by done by a
Collect
There is no value in making users remember which stream methods are
null-hostile and which are null-tolerant; this is just more accidental
complexity.
I think that ship has sailed a long ago.
Some collectors are null hostile, some are not.
You can make a point that a Collector is technically n
As for nullity topic, I really welcome that the proposed toList() is
null-tolerant but it worth mentioning that existing terminal
operations like findFirst(), findAny(), min() and max() are already
null-hostile.
The min() and max() methods are not null hostile. If you pass a
null-friendly com
I wonder if we should not do the same with toList(), having toList() to be equivalent to
collect(Collectors.toUnmodifiableList()) and toList(IntFunction>)
allowing to use a null friendly List implementation like ArrayList.
If you pull on this string all the way, we end up with "let's just n
On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
But after thinking about it, I'm now convinced that it would be a bad
idea. Because it extends the scope of this small, tiny Iterable
interface to something bigger which it shouldn't be.
This response captures the essence of the problem. You m
https://github.com/graalvm/labs-openjdk-11/commit/00b9ecd85dedd0411837eee33635dd83e8b7def8
and initializes them with Unsafe as an optimization
https://github.com/graalvm/labs-openjdk-11/commit/273e8590a7b57c0c10d9213ca9e0ba581e2817b8
After the discussion with Brian Goetz, we have trimmed
For those that are not intimately familiar with the mechanics of proxy
class generation, it would be great to flesh this out with a code
example, that shows the proposed old and new translation. This would
make it easier for folks to evaluate the benefits and costs of the
approach, and possibly
t espace. So, again, doing it by hand this time.
>
> On 22.11.2019 20:52, Brian Goetz wrote:
> > For those that are not intimately familiar with the mechanics of proxy
> > class generation, it would be great to flesh this out with a code example,
> > that shows the proposed
I just finished the first prototype, which can be found at
https://gist.github.com/DasBrain/7766bedfbc8b76ba6a0ee66a54ba97ed - it
contains a patch, the javap output of a generated proxy class with and
without that patch, and the code I used to dump the proxy class. "make
run-test-tier1" pass
Finally, we can benchmark the current approach against the LDC
approach on a per-Method basis. The LDC approach may well be doing
more work per Method, so it's a tradeoff to determine whether
deferring that work is a win.
By this last bit, I mean JMH'ing:
Method m1() {
return
hods of a proxy are public (can
only proxy interfaces), the interesting access control is done on the
class lookup. This would result in similar costs for looking up the
Method, but delaying it to first use (still paying the one-by-one condy
dispatch vs doing them all as a group in .)
On 11/23/2019
Overall, the approach seems sound, and I like that you are introducing only one
new bootstrap that is usable for a range of things. A few comments and
questions.
1. Not sure the explicit source type carries its weight, but whether it does
or not is probably informed by whatever we do for (3
I have been reading previous threads, the original bug request, and exploring
the javadoc and implementation of toList() on Stream in JDK 16. I don’t want to
waste time rehashing previous discussions, but I want to understand and
prioritize the motivation of this change, and propose what I b
Looks good! Glad to see the Amber features finding their way into the
codebase.
On 3/8/2021 1:53 PM, Patrick Concannon wrote:
Hi,
Could someone please review my code for updating the code in the `java.io`,
`java.math`, and `java.text` packages to make use of the `instanceof` pattern
variabl
These patches are obviously minimally correct. However, for equals
methods at least, I would take them one step further, from:
if (!(o instanceof Key that)) return false;
//noinspection StringEquality (guaranteed interned String(s))
return name == that.name &
Overall, I'd be happy to see Decimal types that are aimed at "reasonable
precision" in addition to the infinite precision that BD offers. (After
Valhalla, of course.)
On 3/29/2021 4:14 PM, Raffaello Giulietti wrote:
Hello,
I'm experimenting with an implementation of Decimal64 and Decimal12
They'll find a natural home in JDBC, since SQL has a native decimal type.
On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:
As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and f
Project Valhalla will allow Instant to be migrated to a primitive class,
which would address your problem.
On 4/2/2021 7:47 PM, Ralph Goers wrote:
Log4j 2 supports the notion of a PreciseClock - one that can be initialized to
something more precise than a millisecond. At the same time it also
Adding a REVERSIBLE characteristic to spliterators is easy enough, and
as you say, many useful sources can easily provide an efficient reverse
operation. Filtering and mapping can preserve reversibility. The real
question is what to do if someone calls reverse() on a non-reversible
stream. (F
This has come up before. For example, during an early iteration of the
Stream design, before parallelism entered the picture. The first
scrawled-on-a-napkin prototype for streams was based on Iterator, and it
took about a minute to realize that we could do a much better job if we
had a slight
Is there a compelling example of where this would be used by clients?
Here are some examples:
https://stackoverflow.com/questions/10988634/java-global-isempty-method
Without passing judgment on the sort of dynamically typed programs that
need a method like this, or wondering what monstrositie
This is basically Spliterator, an iterator + a size, with the iterator is "push" instead
of "pull" because it's more efficient.
In details a Spliterator is either
- an Iterable (with no SIZED characteristic)
- an Iterable + size (if SIZED and estimateSize() != Long.MAX_VALUE)
- an Iterable +
While I agree that we should be careful, let's not paint ourselves into
an either/or strawman. The choice is not "never add anything to
Collection" vs "let's dump every silly idea that comes to anyone's mind
into Collection"; it is, as always, going to involve tradeoffs between
stability and e
Yes, this has been considered at some length. The summary verdict is:
- Method references for static/unbound methods seem like reasonable
constant literals to put in annotations, not unlike class literals.
- Lambdas, on the other hand: absolutely, positively, not.
To actually get to method
There may be some JDK code that checks for anon classes by comparing the name
to see if it contains a slash, especially tests, but which don’t say
“anonymous”. Did you do a search for these idioms too, which are now dead
tests?
Sent from my iPad
> On May 11, 2021, at 8:59 AM, Harold Seigel w
Yes, please!
To add to the list of motivations/things to remove: the current
implementation relies on the special `MagicAccessorImpl` to relax
accessibility. The notes in this class are frightening; getting rid of
it would be a mercy.
On 5/11/2021 4:42 PM, Mandy Chung wrote:
This draft JE
Scope locals have come together nicely.
I have some vague thoughts on the presentation of the JEP draft. There
are (at least) three intertwined things in the motivation:
- ThreadLocal (and ITL especially) were always compromises, and with
the advent of Loom, have become untenable -- but the
ning a slash is
still valid (I haven't found any of such test though).
Mandy
On 5/11/21 6:20 AM, Brian Goetz wrote:
There may be some JDK code that checks for anon classes by comparing the name
to see if it contains a slash, especially tests, but which don’t say
“anonymous”. Did you d
Its simpler than you're making it. Think of the motivating use cases
for ThreadLocal, such as when a container calls into user code, and the
user code calls back into the container, and we need to keep track of
{transaction, security, etc} context, and it is impractical to pass them
all throug
The lifecycle is bounded by the duration of the Runnable passed to the
`run()` method.
In the simple case, with no inheritance and no snapshotting:
ScopedLocal.where(x, xExpr).run(r)
the lifecycle of the binding starts when we enter r, and ends when we
return from r.
With snapshotting,
How so? How do I know if a snapshot of my variable has occurred?
Let's back up a lot of steps; you're deep in proposing a solution when
you've not even explained what problem you think you're solving. So
control question, which I hope will start to expose the assumptions:
Why do you t
Let's back up a lot of steps; you're deep in proposing a solution
when you've not even explained what problem you think you're
solving. So control question, which I hope will start to expose
the assumptions:
Why do you think its important to know that a snapshot of a
Let's try again: why is that important? What decisions would you
make differently if you had this information? What benefit would
come from those decisions?
Threading is hard.
Gee, thanks MIke for pointing that out to me, obviously I'm new to the
topic :)
Scoped variables a
Has it ever been conceived to create an entire new API like how it was
done for Dates and Times? Obviously this would be a massive
undertaking, but it seems to me we've just about reached the limits of
how far we can stretch the current API.
"This code is a mess, we should throw it away and r
There is no end to patterns of code that could be generated by tools, and for
each of them, one can imagine situations where they would be useful. But in
addition to the other reply about how builders are really only called for when
there are a large number of _optional_ components, the premise
rstood Brian, great answer.
>
> Could you please answer to my other proposal?:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077955.html
>
> Regards,
>
> Alberto.
> ________
> De: Brian Goetz
> Enviado: sábado, 22 de mayo de
In the last hunk, you convert
case Collator.IDENTICAL: toAddTo.append('='); break;
case Collator.TERTIARY: toAddTo.append(','); break;
case Collator.SECONDARY: toAddTo.append(';'); break;
case Collator.PRIMARY: toAddTo.append('<'); break;
case RESET: toAd
On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote:
>> Inspired by PR#4088. Most of the changes are done automatically using
>> IntelliJ IDEA refactoring. Some manual adjustments are also performed,
>> including indentations, moving comments, extracting common cast out of
>> switch expres
On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote:
>> Inspired by PR#4088. Most of the changes are done automatically using
>> IntelliJ IDEA refactoring. Some manual adjustments are also performed,
>> including indentations, moving comments, extracting common cast out of
>> switch expres
Since the discussion happened over the holiday weekend, I didn't get a
chance to respond until now, but I think that this came to a good
outcome. As Alan's archaeology discovered, this flag appears to be a
leftover from the original implementation, and I could find no signs of
its usage. We m
The motivation here is that we wanted to preserve the ability to
describe "special" indy sites with special objects. The standard
implementation can describe any indy site (bootstrap, static args,
invocation name and type), but some indy sites (e.g., lambda capture)
are "special". It would be
It seems pretty clear that this "feature" is a leftover from an early
implementation, doesn't clearly say what it is supposed to do, is more
complicated than it looks, and is buggily implemented. While I
understand the temptation to "fix" it, at this point we'd realistically
be adding a basica
On 6/7/2021 5:51 AM, Remi Forax wrote:
Hi all,
the first part of the message is about javac error message that could be
improved,
the second part is about the current spec being not very logical.
With this code
Object o = null;
var value = switch(o) {
//case null -> 0;
Bootstrap methods are cheap. If you have one that is semantically
different, better to write a separate bootstrap than to try and cram two
sets of functionality into one. So +1 for "make a new bootstrap for enums."
On 6/16/2021 11:25 AM, Jan Lahoda wrote:
Currently, an enum switch with patter
You might also consider bringing this to panama-dev, since that will
eventually be the recommended replacement for most uses of JNI.
On 7/21/2021 6:25 PM, David Holmes wrote:
Hi Hans,
On 22/07/2021 7:54 am, Hans Boehm wrote:
Is this an appropriate list to discuss JNI?
No - hotspot-dev (to g
Starting with a PR is not the way to add significant API surface to the JDK.
You have to first build consensus on the mailing list for the design concept
before we start talking about code.
FTR, Interfaces like these were already discussed and rejected in the JSR 335
design discussions.
On Mon, 9 Aug 2021 12:28:23 GMT, CC007
wrote:
> create Streamable and ParallelStreamable interface and use them in Collection
> and Optional
I object to this change. These issues were explored in the JSR 335 EG and it
was agreed that this abstraction did not carry its weight. In any case, i
On Mon, 9 Aug 2021 12:28:23 GMT, CC007
wrote:
> create Streamable and ParallelStreamable interface and use them in Collection
> and Optional
I understand what you are proposing. I do not believe Streamable carries its
weight.
Sent from my iPad
> On Aug 14, 2021, at 8:53 PM, CC007 ***@**
On Mon, 9 Aug 2021 12:28:23 GMT, CC007
wrote:
> create Streamable and ParallelStreamable interface and use them in Collection
> and Optional
To reiterate: These issues were explored in the JSR 335 EG and it was agreed
that this abstraction did not carry its weight. In any case, it is prematur
For the third time: This discussion illustrates why the PR was
premature; the design was not agreed upon first. High-level design
discussions (i.e., "is this a good design", "is this a good idea at
all", "are we solving the right problem", "does it need to be solved in
the JDK") should happen
This was an early attempt at the functionality provided by LambdaMetafactory.
It could probably be reimplemented on top of that, but probably could be
deprecated in favor of LMF as well.
Sent from my iPad
> On Aug 22, 2021, at 10:08 PM, liangchenb...@gmail.com wrote:
>
> Currently, java.lan
+1
On 8/23/2021 2:22 PM, Vicente Romero wrote:
Please review this simple PR along with the associated CSR. The PR is basically
adding a line the the specification of method
`java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a
NPE will be thrown.
TIA
link to the [CSR]
);
requireNonNull(names);
requireNonNull(getters);
On 8/23/2021 4:04 PM, Brian Goetz wrote:
+1
On 8/23/2021 2:22 PM, Vicente Romero wrote:
Please review this simple PR along with the associated CSR. The PR is
basically adding a line the the specification of method
`java.lang.runtime.ObjectMethods
In Java 8, I think we were reluctant to lean on the idiom of "pass me a
lambda and I'll pass it the confined data"), because Java developers
were already struggling to understand lambdas. But now that we're
mostly over that hurdle, API points that accept Consumer are
a powerful way to gain con
I am not really sure we’ve gotten the right idiom here yet. I’d like to slow
down a bit before making an API decision.
What id suggest is capturing the proposed api and spec on list, and let’s let
this sit and bake for a bit longer. My sense is that something better may well
emerge if we do
I would suggest that we hold this patch until the string interpolation
JEP lands. It will offer both better readability *and* better
performance, and probably better to have one round of "replace all the
toString implementations" than two?
On 11/10/2021 1:04 PM, Eamonn McManus wrote:
Use str
While I'm the first to admit that the design of annotations incorporated
a great deal of optimism about its sufficiency, I think the
return-on-complexity for such things is not good enough to warrant
working on this.
Now I was thinking: wouldn't it be nice to be able to define a custom
defaul
I don’t see how a restricted reference by itself is useful, if you cannot
depend upon the object not being mutated via other references.
Agree; this may help you do local proofs of correctness, and may conceivably
help the JIT (though, its pretty smart about figuring this stuff out on its
own),
As the language currently stands, new means new; it is guaranteed to create a
new identity. (When Valhalla comes along, instances of certain classes will be
identity-free, so the meaning of new will change somewhat, but String seems
likely to stay as it is.)
The language is allowed (in some
Are you proposing dropping SIZED from the spliterator for arrays? This
would undermine all the array-based optimizations (e.g., toArray), which
seems a bad trade. I realize the splitting heuristics are frustrating
for a number of use cases, but this seems like throwing the baby out
with the b
It's a time-honored tradition in naming bikesheds to pick and choose the
precedents you want to be "consistent" with, and I think that's what's
going on here with your preference for "Ordered" over "Sequenced". But
in an ecosystem as large as Java, you can always find conflicting
precedents to
Yes, and ...
There are words of flags elsewhere scattered through the JDK, such the
InnerClasses attribute, module flags in the Module attribute, and flags
on the "requires" entries in the Module attribute. Having one
abstraction to cover all these locations, even though reflection doesn't
c
You keep saying “what we need”. But really, what I think you mean is “what the
scheme I have in mind needs.” Can we try and separate these out? I don’t
think any of these are *needed*, but maybe you want to make the argument that
you have a better scheme in mind, and we should choose that sch
It is a base assumption that the specific representation — bits in an int[], a
class per shape, a cache of common shapes, etc — is a pure implementation
detail that can be changed at will, based on various tradeoffs like
footprint-vs-startup that can be made at any time. The only assumption is
MethodType is a useful shape for describing a pattern, in reverse; the
“parameter” types are really the pattern bindings, and the “return” type is
really the (minimal) type of the target. With such a description, the
MethodType for a pattern is the right input to get the carrier for the pattern
This is a nice use of `mapMulti` to create a stream whose contents are
dynamically generated. It is one step short of generators (which we
hope Loom will eventually give us), in that it is restricted to a
generator method that generates all of the elements in one invocation.
This is still qui
This work is quite timely as we are now paving the way for primitive
type patterns over in Project Amber, and also has a nontrivial
connection with Valhalla. If you'll pardon a brief digression...
Instanceof and casting work together in a familiar way: before you cast,
you first ask instanceo
Themotivation behind this PR isnot driven by pattern matching:John
Rose (the reporter of the JBS issue) is concerned about having safer
casts that, in addition, can be JITted to efficient code.
Yes, of course. But also, as the platform evolves, it often happens
that the same issues arise
lving
past reference type patterns” in the amber-spec-experts mailing list
of April 2022 don’t even mention the mixed integral/floating-point case.
Greetings
Raffaello
*From: *core-libs-dev on behalf
of Brian Goetz
*Date: *Tuesday, 24 May 2022 at 00:09
*To: *Raffaello Giulietti ,
core-lib
This is a call for proposals for "point lambdafication candidates."
Once we introduce lambda to the language, the libraries immediately
start to look a little older. One subgoal of Project Lambda is to
upgrade the libraries to take better advantage of the new language
features. Of course, th
Wait/notify may be better than sleeping, but semaphore/latch/barrier are much
better than wait/notify. Much.
Sent from my iPhone
On Nov 7, 2011, at 1:28 PM, chris hegarty wrote:
> Hi Gary,
>
> Thanks for taking this bug.
>
> In similar tests I've preferred to use j.u.c.Paser/CountDownLatc
I can recommend a good book
Sent from my iPhone
On Nov 7, 2011, at 4:53 PM, Rémi Forax wrote:
> On 11/07/2011 09:50 PM, Brian Goetz wrote:
>> Wait/notify may be better than sleeping, but semaphore/latch/barrier are
>> much better than wait/notify. Much.
>>
&
> In your subsequent email, I found that the asXXX and toXXX variants to be too
> similar to
> make it clear which throws and which does not or other differences unless it
> were a pervasive
> pattern that all developers would know and use.
We encourage this convention:
- Use "asXxx" to describ
I would think scanning for test files that have a main() method but not a @run
tag would be a good way to find more of these...
On Mar 11, 2012, at 4:21 AM, Alan Bateman wrote:
>
> I was looking at a test and happen to notice that it had a @build tag but no
> @run tag so the test wasn't actual
Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit framework. Is
there already an existing example?
There's good news on this front. We are in the process of making TestNG
a supported test framework for writing uni
Yes. We'll be migrating those to TestNG as part of the process.
On 3/30/2012 4:35 PM, Ulf Zibis wrote:
Am 30.03.2012 19:38, schrieb Brian Goetz:
Similarly class Infrastructure could be reused over all JDK's tests. But
personnally I would prefer to more and more use the JUnit fra
;good enough"), we chose the path of "let's get something done."
On 4/2/2012 5:28 PM, Ulf Zibis wrote:
Thanks Brian.
Is there any article, why you prefer testNG over JUnit?
-Ulf
Am 02.04.2012 19:47, schrieb Brian Goetz:
Yes. We'll be migrating those to TestNG as part
Reducing the number of SoftReferences in ReflectionHelper also seems an
attractive target for memory reduction. Rather than eight soft
references (eight extra objects), maintaining a SoftRef to the entire
RH, or at least to the part of the RH that is currently SR'ed if the two
non-SR'ed fields
This all looks great.
My only concern is the mention of a "fences" API; I would think that
this might rise to the level of wanting its own JSR, since the memory
model does not necessarily provide for the all various relaxed
consistency modes that such an API would seem to imply, and might
inv
Farther afield: the "Holder" idiom for thread-safe lazy initialization
is one that we could now replace with invokedynamic (since a
ConstantCallSize acts as a lazily initialize cache), if there were only
a way to actually express the indy code from Java. This would let us
replace a class with
Oops, forgot to actually review the patch: approved.
On 5/10/2012 7:11 PM, Mike Duigou wrote:
Hello all;
A benign but potentially expensive race condition was discovered in
java.util.UUID. The initialization of numberGenerator may cause the creation of
a number of SecureRandom instances if mu
From a concurrency perspective it is also preferable to NOT initialize
variables to their default values, as doing so can cause some weird
problems. For example:
class A {
public int x = 0;
public void increment() { ++x; }
public int get() { return x; }
}
// Thread X
// Assume: T
I believe this change is not source compatible. If a user says:
try { clone() }
catch (RuntimeException e) { ... }
catch (CloneNotSupportedException e1) { }
this compiles today but would fail to compile under this change.
On Oct 14, 2012, at 7:06 PM, Mike Duigou wrote:
> Seems reasonab
This code has thread-safety issues. There is no happens-before between the
writes to suppressedExceptions (and its referenced state) and the places where
it is iterated (e.g., line 576).
You could plug this hole by replacing the idiom at line 576 (and similar) with
for (Throwable se : getS
Looks good now. Serialization logic is a little confusing but seems OK.
On Aug 11, 2010, at 4:53 PM, Mandy Chung wrote:
> On 08/11/10 12:35, Brian Goetz wrote:
>> This code has thread-safety issues. There is no happens-before between the
>> writes to suppressedExceptions (and
So, this aspect of COIN is still somewhat new, and so I think it is worth
looking at carefully. There is a specification for this feature that was
discussed on coin-dev. You might want to take a look and comment -- its not
too late.
On Aug 12, 2010, at 5:00 PM, David Holmes wrote:
> Mandy Ch
Explicit non-objection :)
On Aug 13, 2010, at 9:58 AM, Chris Hegarty wrote:
>
> The issue of whether Threads should be Cloneable came up during the
> discussion of another problem. I talked to David about this and we believe
> there is no value being able to clone a thread, in fact it can caus
Compatibility is not an end unto itself; IMO compatibility with broken
programs is not something we should spend our effort maintaining. I'm +1 on
this change, with final.
On 8/16/2010 5:03 AM, Chris Hegarty wrote:
Thanks everyone for your very valuable feedback.
From what I'm reading there
Mostly style issues, but at least one likely bug.
In a few places, you've used @SuppressWarnings("unchecked"). While this may
well be unavoidable, it is worth factoring this out into the smallest possible
chunk. For BandStructure, you've applied it to the whole class, and there's
some big me
The performance impact of this might be severe when deserializing object
graphs with lots of final fields (and we recommend using final fields wherever
possible.) And, I'm a little unclear on the approach here. If the goal is to
provide a happens-before edge between deserializing an object gra
Is it possible to coalesce the fences so that we don't incur them on every
field write?
On 11/22/2010 10:10 AM, Doug Lea wrote:
On 11/22/10 09:35, Rémi Forax wrote:
This is a patch to default deserialization so that it uses volatile-write when
setting final fields:
http://cr.openjdk.java.net/~
We're in the process of spinning up this effort. We have no answer for you
now other than "there will be some", but as we progress you'll see details
showing up in one or more of: this list, lambda-dev, concurrency-interest.
On 11/24/2010 1:57 PM, Adam Rabung wrote:
Hi,
I would like to learn
1 - 100 of 317 matches
Mail list logo
