Re: RFR: implementation for JEP 334: JVM Constants API
I think using FieldTypeDescriptor is misleading. since that is used for param types and return types. I propose SimpleTypeDescriptor or VariableTypeDescriptor. On Wed, May 23, 2018 at 11:11 PM, Vicente Romero <vicente.rom...@oracle.com> wrote: > Hi all, > > Please review the proposed implementation for JEP 334 [1]. The webrev can > be found at [2] and the javadoc at [3]. > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8203252 > [2] http://cr.openjdk.java.net/~vromero/constant.api/webrev.07/ > constants.api.patch > [3] http://cr.openjdk.java.net/~vromero/constant.api/javadoc.07/ > overview-summary.html > > PS. We are offering a MacBook Wheel to the authors of the first 5 comments > :) > -- Best Regards, Ali Ebrahimi
Re: Fwd: RFR(m): 8140281 deprecate Optional.get()
Hi, I agree with Jon, Vitaly, I think the name Optional completely describe its intents and semantics so I don't think we need more descriptive method name here. Optional === may be have value So Optional.get === may be return value Therefore, I think this all effort doesn't add any (or enough) value, So isn't worth of it (from resource POV). Done side: The all current source codes that uses this method when compiling with java9 get dozen of warnings. On Tue, Apr 26, 2016 at 4:13 AM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > OK. > > The best I can say is that I disagree with the underlying change (to > deprecate Optional.get) but that if the API change is generally agreed to, > then I reluctantly agree with the edit here. > > The bug needs a noreg-label. > > -- jon > > > > > On 04/25/2016 04:37 PM, Stuart Marks wrote: > >> >> >> On 4/25/16 4:27 PM, Jonathan Gibbons wrote: >> >>> Enter.java: >>> It's pretty ugly that the recommended usage is to have to add a >>> SuppressWarnings >>> for a reasonable and valid use of Optional.get. >>> >>> Are you sure this is the API you want? >>> >> >> Ah, I had neglected to explain this one, sorry. >> >> In the majority cases, uses of get() can be refactored away to use one of >> the other Optional methods. >> >> In just about all the remaining cases, the code should use the >> replacement method getWhenPresent(), which has the same semantics as the >> current get() call. This is called for if lambdas should be avoided because >> of startup performance, or because of checked exceptions, or if it's >> provable from context that a value is always present. >> >> The case of Enter.java is a special one; it gets compiled with the boot >> libraries (JDK 8) and getWhenPresent() doesn't exist in those. It doesn't >> generate a warning though. But as you explained to me the other day, this >> code is later recompiled against the JDK 9 libraries, and in that case it >> does generate the warning. >> >> So for this case I think calling get() with @SuppressWarnings is the way >> to proceed. I opted to extract a local variable and put @SW on it, in order >> to minimize its scope, but if you prefer an alternative I'd be happy to >> change it. >> >> s'marks >> > > -- Best Regards, Ali Ebrahimi
Re: Signature of MethodHandleInfo.reflectAs is not specific enough
Hi, On Sat, Mar 1, 2014 at 12:16 AM, John Rose john.r.r...@oracle.com wrote: On Feb 25, 2014, at 3:13 AM, Ali Ebrahimi ali.ebrahimi1...@gmail.com wrote: I know, this is too late, but I want to share my suggestion: public T extends AccessibleObjectAnnotatedElement T reflectAs(Class? super T expected, MethodHandles.Lookup lookup) Isn't this the same as public T extends AccessibleObject T reflectAs... Oh, sorry, this is my bad. I mean this: public T extends AccessibleObjectMember T reflectAs(Class? super T expected, MethodHandles.Lookup lookup) I think we considered AccessibleObject but rejected it as not buying anything significant compared with Member which is an interface. Perhaps public T extends Member AnnotatedElement T reflectAs... I considered this case, but unfortunately compiler accepts following test case with this signature: String ss = reflectAs(String.class, MethodHandles.lookup()); //OK!!! This seams as compiler bug, any way with T extends AccessibleObjectMember compiler catches error. Finally, one case that compiler accepts with both signature is: Object mo = reflectAs(Object.class, MethodHandles.lookup()); Maybe I'm wrong for this, Dan Smith can better interpret this. T inferred to Object and T is not within its bound (AccessibleObjectMember). Regards, Ali Ebrahimi
Re: Signature of MethodHandleInfo.reflectAs is not specific enough
Hi, I know, this is too late, but I want to share my suggestion: public T extends AccessibleObjectAnnotatedElement T reflectAs(Class? super T expected, MethodHandles.Lookup lookup) Member mr = reflectAs(Member.class, MethodHandles.lookup()); AnnotatedElement ae = reflectAs(AnnotatedElement.class, MethodHandles.lookup()); AnnotatedElement am = reflectAs(Member.class, MethodHandles.lookup()); Field fd= reflectAs(Field.class, MethodHandles.lookup()); Constructor cr = reflectAs(Constructor.class, MethodHandles.lookup()); Method md = reflectAs(Method.class, MethodHandles.lookup()); Field fm= reflectAs(Member.class, MethodHandles.lookup()); Constructor cm = reflectAs(Member.class, MethodHandles.lookup()); Method mm = reflectAs(Member.class, MethodHandles.lookup()); Field fa= reflectAs(AnnotatedElement.class, MethodHandles.lookup()); Constructor ca = reflectAs(AnnotatedElement.class, MethodHandles.lookup()); Method ma = reflectAs(AnnotatedElement.class, MethodHandles.lookup()); Member mf= reflectAs(Field.class, MethodHandles.lookup()); Member mc = reflectAs(Constructor.class, MethodHandles.lookup()); Member mrm = reflectAs(Method.class, MethodHandles.lookup()); AnnotatedElement af= reflectAs(Field.class, MethodHandles.lookup()); AnnotatedElement ac = reflectAs(Constructor.class, MethodHandles.lookup()); AnnotatedElement aem = reflectAs(Method.class, MethodHandles.lookup()); Method mdc = reflectAs(Constructor.class, MethodHandles.lookup());//fails Constructor crm = reflectAs(Method.class, MethodHandles.lookup());//fails Constructor cf = reflectAs(Field.class, MethodHandles.lookup());//fails Field fc = reflectAs(Constructor.class, MethodHandles.lookup());//fails AnnotatedElement as = reflectAs(String.class, MethodHandles.lookup());//fails String ss = reflectAs(String.class, MethodHandles.lookup());//fails String sm = reflectAs(Method.class, MethodHandles.lookup());//fails Regards, Ali Ebrahimi On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax fo...@univ-mlv.fr wrote: The is a stupid issue with the signature of MethodHandleInfo.reflectAs, j.l.r.Field, Method or Constructor implement two interfaces Member and AnnotatedElement, with the current signature, the code info.reflectAs(Member.class, lookup) works but the code info.reflectAs(AnnotatedElement.class, lookup) doesn't work. Because there is no way to do an 'or' between several bounds of a type variable, I think that the signature of reflectAs should be changed from : public T extends Member T reflectAs(ClassT expected, Lookup lookup); to public T T reflectAs(ClassT expected, Lookup lookup); and the javadoc should be modified to explain that a Member or AnnotatedElement are valid bounds of T. As a side effect, the signature of MethodHandles.reflectAs(ClassT, MethodHandle) should be updated accordingly. There is a workaround, one can write: (AnnotatedElement)info.reflectAs(Member.class, lookup) but it's at best weird. cheers, Rémi ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Signature of MethodHandleInfo.reflectAs is not specific enough
Hi,
I know this is not fully type safe, in fact java generics is not fully type
safe.
We don't have any better solution with current language support.
if we had:
T extends A|B
or
T super R
we had better solutions:
public T extends Member | AnnotatedElement T reflectAs(ClassT expected,
Lookup lookup)
public T extends Member AnnotatedElement, R super T R reflectAs(Class?
super T expected, Lookup lookup)
but we don't have such support in language.
But I think there is another solution that require change in j.l.r API
Make Member an AnnotatedElement
interface Member implements AnnotatedElement { ...}
and
public T extends AnnotatedElement T reflectAs(ClassT expected, Lookup
lookup)
On Mon, Nov 11, 2013 at 10:44 AM, Peter Levart peter.lev...@gmail.comwrote:
On 11/11/2013 02:24 AM, Ali Ebrahimi wrote:
This is another workaround:
public T extends MemberAnnotatedElement, R R reflectAs(Class? super T
expected, Lookup lookup);
info.reflectAs(Member.class, lookup);//works
info.reflectAs(AnnotatedElement.class, lookup);//works
info.reflectAs(Member.class, lookup);//works
info.reflectAs(AnnotatedElement.class, lookup);//works
info.reflectAs(Object.class, lookup);doesn't work.
info.reflectAs(Other.class, lookup);doesn't work.
with this does not need to your javadoc and is more type safe. .
Hm... it doesn't look very compile-time type-safe:
String s = info.reflectAs(Method.class, lookup); // compiles !!!
IMO, I would rather remove the Class parameter altogether. It serves no
purpose in the method implementation other than to perform a cast-check on
the returned object. The method could simply be:
public T extends Member T reflect(Lookup lookup);
This would not solve the problem Remi put forward. I.e. this would not
compile:
AnnotatedElement ae = info.reflect(lookup);
But with an explicit cast, It compiles:
AnnotatedElement ae = (AnnotatedElement) info.reflect(lookup);
And compared to what we would have with Class parameter and loosened
compile-time type-safety as per Remi's suggestion, it is still shorter:
AnnotatedElement ae = info.reflectAs(AnnotatedElement.class, lookup);
// this is longer!
A type-unsafe variant is possible too (I'm not advocating it):
public T T reflect(Lookup lookup);
Now that Generalized Target-Type
Inferencehttp://openjdk.java.net/projects/jdk8/features#101is part of Java
8, using ClassT parameters just as hints to the compiler
is not needed in many cases. But if one needs to hint the compiler,
explicit type parameters can be used as an escape hatch as always:
Object o = info.Methodreflect(lookup);
Regards, Peter
On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax fo...@univ-mlv.fr wrote:
The is a stupid issue with the signature of MethodHandleInfo.reflectAs,
j.l.r.Field, Method or Constructor implement two interfaces Member and
AnnotatedElement, with the current signature, the code
info.reflectAs(Member.class, lookup)
works but the code
info.reflectAs(AnnotatedElement.class, lookup)
doesn't work.
Because there is no way to do an 'or' between several bounds of
a type variable, I think that the signature of reflectAs should be
changed from :
public T extends Member T reflectAs(ClassT expected, Lookup
lookup);
to
public T T reflectAs(ClassT expected, Lookup lookup);
and the javadoc should be modified to explain that a Member or
AnnotatedElement are
valid bounds of T.
As a side effect, the signature of MethodHandles.reflectAs(ClassT,
MethodHandle)
should be updated accordingly.
There is a workaround, one can write:
(AnnotatedElement)info.reflectAs(Member.class, lookup)
but it's at best weird.
cheers,
Rémi
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing
listmlvm-...@openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Signature of MethodHandleInfo.reflectAs is not specific enough
This is another workaround: public T extends MemberAnnotatedElement, R R reflectAs(Class? super T expected, Lookup lookup); info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works info.reflectAs(Object.class, lookup);doesn't work. info.reflectAs(Other.class, lookup);doesn't work. with this does not need to your javadoc and is more type safe. . On Mon, Nov 11, 2013 at 1:59 AM, Remi Forax fo...@univ-mlv.fr wrote: The is a stupid issue with the signature of MethodHandleInfo.reflectAs, j.l.r.Field, Method or Constructor implement two interfaces Member and AnnotatedElement, with the current signature, the code info.reflectAs(Member.class, lookup) works but the code info.reflectAs(AnnotatedElement.class, lookup) doesn't work. Because there is no way to do an 'or' between several bounds of a type variable, I think that the signature of reflectAs should be changed from : public T extends Member T reflectAs(ClassT expected, Lookup lookup); to public T T reflectAs(ClassT expected, Lookup lookup); and the javadoc should be modified to explain that a Member or AnnotatedElement are valid bounds of T. As a side effect, the signature of MethodHandles.reflectAs(ClassT, MethodHandle) should be updated accordingly. There is a workaround, one can write: (AnnotatedElement)info.reflectAs(Member.class, lookup) but it's at best weird. cheers, Rémi ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Review: lamda expressions and bulk data operations on collections.
I see nobody using mangled (comparingmap) methods (even oracle guys) and this is the thing that I already have expected, just since we all lazy and this would hurt performance. This issue would be a candidate topic for next edition of Joshua Bloch's Effective Java. So to prevent this I propose following names: mapR map (R === Reference Type) mapI mapToInt mapL mapToLong mapD mapToDouble comparingR comparing comparingI comparingInt comparingL comparingLong comparingD comparingDouble All method names have same length. Best Regards, Ali Ebrahmi On Sat, Aug 31, 2013 at 12:07 AM, Andrey Nazarov andrey.x.naza...@oracle.com wrote: Webrev is here http://cr.openjdk.java.net/~anazarov/jdk8-demo-bulkoperations/webrev.00/ http://cr.openjdk.java.net/%7Eanazarov/jdk8-demo-bulkoperations/webrev.00/ Mail server removes attachments. --Andrey On 29.08.2013 23:38, Alan Bateman wrote: On 29/08/2013 19:33, Andrey Nazarov wrote: Hi guys, We want to push our demo code for lambda expression and bulk data operations. Could you please review this code? Webrev is attached. --Andrey. Your mail didn't have an attachment, it probably was dropped by the mail server. Can you publish on a HTTP server so that it can be browsed? -Alan.
Re: RFR: 8023681: Fix raw type warning caused by Sink
Why not to make castingIdentity method a constant? On Fri, Aug 23, 2013 at 11:47 PM, Henry Jen henry@oracle.com wrote: Hi, Please kindly review the fix for eliminate some warnings in java.util.stream package. Chained Sink is an internal implementation detail, add the type for downstream is more precise but verbose. Included is also a couple other warnings cleanup. http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/ Cheers, Henry
Re: RFR: 8023681: Fix raw type warning caused by Sink
you can try this.
private static Function?,? CASTING_IDENTITY = i - i;
@SuppressWarnings(unchecked)
private static I, R FunctionI, R castingIdentity() {
return (FunctionI, R) CASTING_IDENTITY;
}
On Sat, Aug 24, 2013 at 2:10 AM, Mike Duigou mike.dui...@oracle.com wrote:
I considered that as well but since the types are generics you'd have to
cast anyway.
The only viable declaration is:
private static Function?,? CASTING_IDENTITY = i - i;
On usage you'd have to add (FunctionI,R) CASTING_IDENTITY
(Which assumes the compiler would even accept this heinous cast, I haven't
tried it)
Mike
On Aug 23 2013, at 14:18 , Ali Ebrahimi wrote:
Why not to make castingIdentity method a constant?
On Fri, Aug 23, 2013 at 11:47 PM, Henry Jen henry@oracle.com
wrote:
Hi,
Please kindly review the fix for eliminate some warnings in
java.util.stream package.
Chained Sink is an internal implementation detail, add the type for
downstream is more precise but verbose.
Included is also a couple other warnings cleanup.
http://cr.openjdk.java.net/~henryjen/tl/8023681.0/webrev/
Cheers,
Henry
Breaking Changeset: 4802647: Throw required NPEs from removeAll()/retainAll()
when building openjfx8 with jdk8b92 i encountered this error :
Total time: 5.313 secs
:buildSrc:clean
:buildSrc:generateGrammarSource
error(10): internal error: Can't get property indirectDelegates using
method ge
t/isIndirectDelegates from org.antlr.tool.Grammar instance :
java.lang.NullPointerException
java.util.Objects.requireNonNull(Objects.java:203)
java.util.ArrayList.removeAll(ArrayList.java:674)
org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222)
org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:43)
java.lang.reflect.Method.invoke(Method.java:491)
org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563)
org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514)
org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416)
org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java
:351)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136)
org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEval
uator.java:216)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84
)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722)
org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86
)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722)
org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86
)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722)
org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86
)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.codegen.CodeGenerator.write(CodeGenerator.java:1278)
org.antlr.codegen.Target.genRecognizerFile(Target.java:94)
org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:463)
org.antlr.Tool.generateRecognizer(Tool.java:607)
org.antlr.Tool.process(Tool.java:429)
org.antlr.Tool.main(Tool.java:91)
:buildSrc:generateGrammarSource FAILED
the cause of this error is this new changeset:
4802647: Throw required NPEs from removeAll()/retainAll()
current code assume that collection.removeAll(null) doesn't do anything.
but with this changeset produces NullPointerException that doesn't handled.
following is part of source code org/antlr/tool/CompositeGrammar.java
(see
)
217 /** Get delegates below direct delegates of g */
218 public ListGrammar getIndirectDelegates(Grammar g) {
219 ListGrammar direct = getDirectDelegates(g);
220 ListGrammar delegates = getDelegates(g); 221
delegates.removeAll(direct);
222 return delegates;
223 }
224
225 /** Return list of delegate grammars from root down to g.
226* Order is root, ..., g.parent. (g not included).
227*/
228 public ListGrammar getDelegators(Grammar g) {
229 if ( g==delegateGrammarTreeRoot.grammar ) {
230 return null;** 231 }
232 ListGrammar grammars = new ArrayList();
233 CompositeGrammarTree t =
delegateGrammarTreeRoot.findNode(g);
234 // walk backwards to root, collecting grammars
235 CompositeGrammarTree p = t.parent;
236 while ( p!=null ) {
237 grammars.add(0, p.grammar); // add to head so
in order later
238 p = p.parent;
239 }
240 return grammars; 241 }
So this changeset at least breaks 'antlr' third-party library and any apps
depends on.
Re: Breaking Changeset: 4802647: Throw required NPEs from removeAll()/retainAll()
What we this:
previous result: before changeset
collection.removeAll(null) do nothing if collection is empty
collection.removeAll(null) NullPointerException if collection is not empty
current result: after changeset
collection.removeAll(null) NullPointerException if collection is empty
collection.removeAll(null) NullPointerException if collection is not empty
solutions:
solution1: backout/revert changeset
solution2: patch changeset
public boolean removeAll(Collection? c) {
if(!isEmpty()) Objects.requireNonNull(c);
boolean modified = false;
Iterator? it = iterator();
while (it.hasNext()) {
if (c.contains(it.next())) {
it.remove();
modified = true;
}
}
return modified;
}
public boolean retainAll(Collection? c) {
if(!isEmpty()) Objects.requireNonNull(c);
boolean modified = false;
IteratorE it = iterator();
while (it.hasNext()) {
if (!c.contains(it.next())) {
it.remove();
modified = true;
}
}
return modified;
}
this is behaviorally compatible change.
On Tue, Jun 4, 2013 at 2:08 PM, Alan Bateman alan.bate...@oracle.comwrote:
On 04/06/2013 10:14, Ali Ebrahimi wrote:
:
the cause of this error is this new changeset:
4802647: Throw required NPEs from removeAll()/retainAll()
current code assume that collection.removeAll(null) doesn't do anything.
but with this changeset produces NullPointerException that doesn't
handled.
following is part of source code org/antlr/tool/**CompositeGrammar.java
(see
)
217 /** Get delegates below direct delegates of g */
218 public ListGrammar getIndirectDelegates(Grammar g) {
219 ListGrammar direct = getDirectDelegates(g);
220 ListGrammar delegates = getDelegates(g); 221
delegates.removeAll(direct);**
222 return delegates;
223 }
224
225 /** Return list of delegate grammars from root down to g.
226 * Order is root, ..., g.parent. (g not included).
227 */
228 public ListGrammar getDelegators(Grammar g) {
229 if ( g==delegateGrammarTreeRoot.**grammar ) {
230 return null;** 231 }
232 ListGrammar grammars = new ArrayList();
233 CompositeGrammarTree t = delegateGrammarTreeRoot.
**findNode(g);
234 // walk backwards to root, collecting grammars
235 CompositeGrammarTree p = t.parent;
236 while ( p!=null ) {
237 grammars.add(0, p.grammar); // add to
head so in order later
238 p = p.parent;
239 }
240 return grammars; 241 }
So this changeset at least breaks 'antlr' third-party library and any apps
depends on.
Thanks for the bug report. It does seem to have exposed a bug in antlr.
Kevin Rushforth (FX) and Mike Duigou have been looking into the same thing
via 8015656.
-Alan.
Re: Upgrade to JAXP 1.5 Breaks Existing Apps
thanks. On Mon, Jun 3, 2013 at 2:59 PM, Alan Bateman alan.bate...@oracle.comwrote: On 02/06/2013 22:05, Ali Ebrahimi wrote: I update to jdk8b92 and almost all apps deals with xml parsing breaks. in other word, current default value for XMLConstants.ACCESS_EXTERNAL_** DTD property is empty string. This should be at least change to file. Yes, the defaults are problematic and are due to be re-examined (but thanks anyway, it's just more evidence that the right thing is to opt-in to have more secure processing rather than requiring the rest of the world to opt-out). I don't know if you are on jdk8-dev but Joe Wang posted a note about this recently: http://mail.openjdk.java.net/**pipermail/jdk8-dev/2013-May/**002554.htmlhttp://mail.openjdk.java.net/pipermail/jdk8-dev/2013-May/002554.html -Alan.
Upgrade to JAXP 1.5 Breaks Existing Apps
I update to jdk8b92 and almost all apps deals with xml parsing breaks. in other word, current default value for XMLConstants.ACCESS_EXTERNAL_DTD property is empty string. This should be at least change to file.
Re: CFR - updated 8001667: Comparator combinators and extension methods
Hi,
for me this is more readable than current naming.
ComparatorPeople cmp1 = compareWith(People::getFirstName).
thenCompareWith(People::getLastName);
Ali Ebrahimi
On Thu, Mar 7, 2013 at 12:22 AM, Henry Jen henry@oracle.com wrote:
On 03/06/2013 03:28 AM, Ali Ebrahimi wrote:
Hi,
just one suggestion:
rename comparing with compareWith
There was a round of discussion on naming.
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2012-November/000446.html
I have my personal preference among proposals, but EG seems to have come
to a consensus on this.
I don't feel strongly between thenCompare, thenComparing or
thenCompareWith. But we should be consistent between Comparators and
Comparator, and consider that Comparators methods could be static
interface method on Comparator in the future.
Cheers,
Henry
1)
public static T, U extends Comparable? super U ComparatorT
compareWith(Function? super T, ? extends U keyExtractor) {
2)
default ComparatorT thenCompareWith(Comparator? super T other)
Best Regards,
Ali Ebrahimi
On Wed, Mar 6, 2013 at 12:16 AM, Henry Jen henry@oracle.com
mailto:henry@oracle.com wrote:
Hi,
Another update to reflect functional interface renames involved in
the
API, and a bug fix for a regression found earlier.
CCC had been approved. Can we get it reviewed and pushed?
[1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev
Cheers,
Henry
Re: CFR - updated 8001667: Comparator combinators and extension methods
Hi,
just one suggestion:
rename comparing with compareWith
1)
public static T, U extends Comparable? super U ComparatorT
compareWith(Function? super T, ? extends U keyExtractor) {
2)
default ComparatorT thenCompareWith(Comparator? super T other)
Best Regards,
Ali Ebrahimi
On Wed, Mar 6, 2013 at 12:16 AM, Henry Jen henry@oracle.com wrote:
Hi,
Another update to reflect functional interface renames involved in the
API, and a bug fix for a regression found earlier.
CCC had been approved. Can we get it reviewed and pushed?
[1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev
Cheers,
Henry
