On 14/01/2015 02:46, joe darcy wrote:
Hello,
Earlier in JDK 9, a language change was made so that if a resource for
a try-with-resources statement is already final or effectively final,
a new resource variable does *not* need to be declared to manage the
variable.
The java.base module shoul
Kindly reminder
On 12.01.2015 17:37, Konstantin Shefov wrote:
Hello, Chris
You have asked "Have you seen NetworkInterface.getName() return names
with ‘_’, ’.’, or ‘:’ ,or is this theoretical?"
I can answer your question. I have named one of network interfaces on
my Linux desktop like "eth0.
On 13/01/15 10:00, Peter Levart wrote:
Hi Chris,
I stepped back and asked myself what problem(s) we are searching
solution(s) for and tried to see how existing API solves or doesn't
solve them. I think that existing readObject() + GetFields API already
solves most of the problems discussed so fa
Peter F,
I am still struggling with the basic concept of you proposal. Let me see
if I understand it correctly. Does the following describe a similar
scenario as you envisage:
1) For each Serializable type, T, in the deserialized types
hierarchy, starting with the top most ( closest to j
On 13/01/15 00:51, Peter Firmstone wrote:
- Original message -
> On 10/01/15 07:00, Peter Firmstone wrote:
> > Again, thank you all for engaging in discussion of this very difficult
> > topic.
> >
> > While we can't presently check intra object dependencies during
> > deserializatio
On 14/01/2015 11:14, Konstantin Shefov wrote:
Kindly reminder
Did we establish if this requires a specification change to clarify the
characters allowed in the host component?
-Alan
Hi Chris,
Sorry, no.
Currently when an ObjectStreamClass is read in from the stream, the framework
searches for the first zero arg constructor of a non serializable class and
creates and instance of the class read and resolved from the stream, however it
does so using a super class constructor
This test currently completes successfully, but indicates that it has
"Parsed 0 classfiles". It doesn't do anything useful.
The modular image no longer contains jar files. The test should use the
JRT FileSystem to iterate over the image classfiles.
http://cr.openjdk.java.net/~chegar/8061297/w
On 14/01/15 12:58, Peter Firmstone wrote:
Hi Chris,
Sorry, no.
Currently when an ObjectStreamClass is read in from the stream, the
framework searches for the first zero arg constructor of a non
serializable class and creates and instance of the class read and
resolved from the stream, however i
On 14/01/2015 13:55, Chris Hegarty wrote:
This test currently completes successfully, but indicates that it has
"Parsed 0 classfiles". It doesn't do anything useful.
The modular image no longer contains jar files. The test should use
the JRT FileSystem to iterate over the image classfiles.
h
On Jan 14, 2015, at 2:55 PM, Chris Hegarty wrote:
> This test currently completes successfully, but indicates that it has "Parsed
> 0 classfiles". It doesn't do anything useful.
>
> The modular image no longer contains jar files. The test should use the JRT
> FileSystem to iterate over the im
On 14.01.2015 15:56, Alan Bateman wrote:
Did we establish if this requires a specification change to clarify
the characters allowed in the host component?
Here
http://docs.oracle.com/javase/7/docs/api/java/net/Inet6Address.html#scoped
we can see that
"The scope_id refers to an interface on th
Hi,
Loosely related to this topic, there is some local variable caching of
comparableClassFor() result already being performed inside
iterative/recursive methods of TreeNode, but this caching is just
positive caching, meaning that null return is not cached. For keys that
happen to implement C
Alan, Paul,
Sometimes with these changes you do not want to cloud the significant
body of the change with other refactoring. That said, we are on round
two, so it seems reasonable.
I think I have captured/addressed all comments:
http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/
On 1/14/2015 5:55 AM, Chris Hegarty wrote:
This test currently completes successfully, but indicates that it has
"Parsed 0 classfiles". It doesn't do anything useful.
The modular image no longer contains jar files. The test should use
the JRT FileSystem to iterate over the image classfiles.
On 1/14/2015 8:04 AM, Chris Hegarty wrote:
http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/
Looks okay to me.
In CallerSensitiveFinder.java line 57, 80, 137 - not sure if you were
thinking to pass "pool" to the CallerSensitiveFinder constructor.
Looks like some editing you mea
On 14/01/15 16:18, Mandy Chung wrote:
On 1/14/2015 8:04 AM, Chris Hegarty wrote:
http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/
Looks okay to me.
In CallerSensitiveFinder.java line 57, 80, 137 - not sure if you were
thinking to pass "pool" to the CallerSensitiveFinder construct
Hello,
On 1/13/2015 11:53 PM, Ivan Gerasimov wrote:
Hi!
A useful change!
I agree :-) We haven't publicized the change very much yet, but it is
part of JEP 213, Milling Project Coin,
(http://openjdk.java.net/jeps/213) and went into JDK 9's javac late in 2014.
Might it also make sense to al
Hi Claes, core libs developers,
As promised, we did yesterday our hackathon in the Bulgarian Java User
Group and incorporated the feedback that we got from you. Here is our next
webrev:
http://dmitryalexandrov.net/~bgjug/5050783/webrev.01/
As you can see:
- We got rid of the inner classes altog
While using a lambda is cool in that context,
if someone tries to do a printStackTrace in the LambdaMetafactory (for
debugging purpose by example),
it will be fun to debug.
cheers,
Rémi
On 01/14/2015 08:25 PM, Ivan St. Ivanov wrote:
Hi Claes, core libs developers,
As promised, we did yesterd
Hi Remi,
I tried it and, well, the JDK image now does not even compile classes that
contain lambda expressions:
javac -cp . ./LambdaMetaFactoryTester.java
Exception in thread "main"
Exception: java.lang.BootstrapMethodError thrown from the
UncaughtExceptionHandler in thread "main"
With the old T
It's only top down if there are intra class invariants, in this case invariants
are checked more than once.
This done simply because we can't move up the constructor call chain untill all
child class invariants have been satisfied.
For simpler class relationships, invariant check order is botto
On 01/14/2015 12:37 PM, Chris Hegarty wrote:
What do you think?
I agree completely.
An API at the level that you are proposing will provide the necessary
functionality and flexibility that is required to do validation in
readObject. As you clearly stated, and is already the case, validation
On 1/14/2015 8:31 AM, Chris Hegarty wrote:
On 14/01/15 16:18, Mandy Chung wrote:
On 1/14/2015 8:04 AM, Chris Hegarty wrote:
http://cr.openjdk.java.net/~chegar/8061297/webrev.01/webrev/
Looks okay to me.
In CallerSensitiveFinder.java line 57, 80, 137 - not sure if you were
thinking to pass
The following is a summary of our exploration so far:
We have narrowed down to two options:
A. constructors with static invariant check methods.
B. Continue to use readObject(), we have a proposed solution to the
final field problem and could modify the jvm to register for
finalization lat
Hello,
Please review these changes to address
JDK-8060077 : Class.toGenericString specification doesn't mention
array types
http://cr.openjdk.java.net/~darcy/8060077.0/
Thanks,
-Joe
Chris,
excuse me, I'm not a reviewer but have some questions.
at line 209, classes is actually trying to resolve a path like
"c:\jdk1.9.0\modules", which never exists in JDK directory. It should be
"c:\jdk1.9.0\lib\modules".
207 if (home.resolve("lib").toFile().exists()) {
27 matches
Mail list logo
