Re: Adding an @Immutable annotation to Java
Hello, Quick question, out of curiosity: how would it behave with respect to inheritance? Can a @Immutable class inherit from an non immutable one? if no: that's a bit annoying, no? (fake immutability) Can @Immutable class be subclassed to a non @Immutable one? if no: that's a bit annoying too, no? (downcasting) Since Object is the super class of everything, it sounds like a problem. What have you thought about to handle this concern? Regards, Justin Dekeyser On Thu, Nov 25, 2021 at 9:08 AM Alberto Otero Rodríguez wrote: > > Hi, I was thinking that it could be interesting adding an @Immutable > annotation to Java. It would be a marker annotation for the compiler (similar > to @FunctionalInterface) in order to throw an error if the annotated > class/record has a component that is not @Immutable. > > This means that all existing immutable objects (like the primitive-wrapping > objects and String) should be annotated with @Immutable and the programmer > could, for example, annotate a new record object with @Immutable only if all > its fields are annotated with @Immutable. > > What do you think? > > Regards, > > Alberto Otero Rodríguez.
Re: 'Find' method for Iterable
Hello all,
Were those downsides seriously considered and strongly argued against? :
(1) Iterable belongs to java.lang so, at least from how it is usually
approached, it's a feature at the very level of the language, not a
util feature like Collection. Adding a find on it, is it really
relevant, or should it be concerned with the simple idea of unlocking
the enhanced-for loop syntax?
(2) For the find() method to stop on any Iterable, the Iterable should
have finite size. This mean the size() method can be implemented too,
by this move:
```java
default int size() {
int[] dummy = { 0 };
Predicate falsy = $ -> { dummy[0] += 1; return false; }
find(falsy);
return dummy[0];
}
```
At the very moment an Iterable also has a size(), a Collection
implementation can be provided (since the altering methods add/remove
are optional in this spec). So , long story short:
Adding a find() method on Iterable with a contract that it stops
(stops, and not just linear search time), makes it a Collection. It
really looks like a nonsense. Or maybe you're going to relax the "this
method is guaranteed to stop" from the spec? Is it then still
relevant?
Note: This (2) problem is not a problem for now, because all the utils
that turns Iterable to a collection like stuff, or a Stream, are
actually features *on those latter* classes. Hence it's not a concern
of Iterable itself.
The problem with (1) is really a communication problem: nothing is
made in the Java documentation to clearly indicate whether or not
Iterable should be used businesswise, or is it only for
syntax-enhancement. (The same problem goes for AutoCloseable: you'll
really find two schools out of there.)
(3) To my opinion, most people are using Iterable either from a
collection (where the .stream().filter(p).findAny() makes the job.
It's not perfect but it's quite clear and flexible) or with a
ResultSet, where the SQL procedure could/should be used anyway. The
other cases look so exotic (but I might be wrong) that I really wonder
how a find method on a Iterable (and not Collection) stuff can be felt
so useful and language fundamental, that it should be in the java.lang
package.
Best regards,
Justin Dekeyser
On Tue, Nov 10, 2020 at 7:02 PM Nir Lisker wrote:
>
> Did this discussion get lost?
>
> On Sun, Sep 20, 2020 at 1:27 AM Nir Lisker wrote:
>
> > While it might not be difficult to add a find() method to Iterable, why
> >> limit it to
> >> the find operation, and what about all the other operations available on
> >> Stream?
> >
> >
> > Good question. I would say it's a matter of how much it is used and what
> > it takes to implement it. The find operation is a lot more common than
> > reduce from what I observe, for example, so I wouldn't suggest reduce to be
> > added..A map(Function) operation would require creating a new
> > collection/iterable internally, and that can be messy (you could
> > preemptively create and pass your own, but then I doubt the worthiness of
> > it). forEach already exists. I just don't see anything enticing.
> >
> > Maybe what's necessary is a way to convert an Iterable to a Stream.
> >
> >
> > Most Iterables are Collections and arrays, and these are easy to convert,
> > so I'm not sure if that really helps. Besides,the idea is to avoid Stream,
> > as I've mentioned, due to the cumbersomeness and the overhead of creating a
> > stream. If I need to do
> >
> > iterable.stream().filter(person -> person.id == 123456).findAny/First()
> >
> > then I didn't really solve my problem.
> >
> > On the other hand, your examples use a list. The List interface already
> >> has methods
> >> indexOf/lastIndexOf which search the list for a particular object that's
> >> compared
> >> using equals(). It seems reasonable to consider similar methods that take
> >> a
> >> predicate instead of an object.
> >
> >
> > I could have used a Set just as well. As for indexOf(Predicate), I
> > would say that it is useful (but personally, I hardly ever need the index
> > of an object, I need the object itself). Interestingly,
> > removeIf(Predicate) exists, but remove(Predicate) doesn't. I would
> > think twice before suggesting to add it though.
> >
> > Ultimately, you have access to a lot of analytics and codebase scans. If
> > you know which patterns are used a lot more than others it would be a good
> > guide. If there are a lot of iterations in order to find an object, its
> > index, or to remove it (or something else), perhaps it's worth supplying
> > these methods. After all, forEach(Consumer) exists and it iterates whil
Re: Asking to contribute(?)
Hello,
Thank you for your answer, I appreciate!
Indeed, it is clear to me that if the feature should be a concern of both
String and Stream (or more?), a common contract can be designed.
The impl. you sketch is the more natural one I think. (it's also the one I
gave in the other mailing grap about that toList stuff, so I guess it's ok!)
I am just a bit cold about the idea that the spec will make the compiler's
job, but I guess in Java there is no work around.
I don't know what the community thinks about it.
Regards,
Justin Dekeyser
On Wednesday, November 4, 2020, Rob Spoor wrote:
> On 04/11/2020 14:18, Justin Dekeyser wrote:
>
>> Hello everyone,
>>
>> I have been following this mailing list for several months, and
>> earlier today my attention was drawn to
>> https://bugs.openjdk.java.net/browse/JDK-8140283. Actually I've been
>> dreaming of such a feature for a long time now.
>>
>> I would really be interested in solving it, but I do not know its
>> current state nor if someone would agree to sponsor my work on that.
>>
>> It would be my very first intervention in the Java code base.
>> (Still have to make sure the Oracle agreement paper does not conflict
>> with my current job contract, so nothing's ready for now.)
>>
>> Thank you for your time,
>>
>> Best regards,
>>
>> Justin Dekeyser
>>
>>
> I'd like this feature as well, but why stop at Stream? String already has
> the transform method, but StringBuilder (and StringBuffer) could also use
> it.
>
> And that's where you're likely to start copy pasting. I've done so for
> several builder classes I've written for myself. So here's a thought: why
> add this method to classes, when you can create a trait using an interface
> with a default method?
>
> public interface Transformable {
>
> default R transform(Function f) {
> // note: this would need documentation that a class X is
> // only allowed to implement Transformable
> return f.apply((T) this);
> }
> }
>
> So you could get the following, and each would automatically get the
> transform method:
> * public class String implements Transformable
> * public class StringBuilder implements Transformable
> * public class StringBuffer implements Transformable
> * public interface Stream implements Transformable>
>
Asking to contribute(?)
Hello everyone, I have been following this mailing list for several months, and earlier today my attention was drawn to https://bugs.openjdk.java.net/browse/JDK-8140283. Actually I've been dreaming of such a feature for a long time now. I would really be interested in solving it, but I do not know its current state nor if someone would agree to sponsor my work on that. It would be my very first intervention in the Java code base. (Still have to make sure the Oracle agreement paper does not conflict with my current job contract, so nothing's ready for now.) Thank you for your time, Best regards, Justin Dekeyser
Re: RFR: 8180352: Add Stream.toList() method
Hello,
Ah that's a super good news, thanks a lot for sharing !
I dream of this since 2 years <3
Best regards,
Justin Dekeyser
On Wed, Nov 4, 2020 at 10:24 AM Tagir Valeev wrote:
>
> Hello!
>
> On Wed, Nov 4, 2020 at 4:16 PM Justin Dekeyser
> wrote:
> > What about trying to make the Stream interface *flexible* to users,
> > instead of adding new functionalities that we could regret later?
> > Then, as the language usages and the trends evolve, we could really
> > see which of the "utils" functions are relevant to add.
> >
> > For example, we could maybe invent a method of the form (just a
> > sketch, not an actual well thought proposal)
> > `
> > default > S wrap(Function, S> wrapper) {
> >return wrapper.apply(this);
> > }
> > `
> > on Stream interface, in such a way one could use the "natural flow"
> > of writing while binding its own implementation and, therefore, use
> > its own shortcuts.
>
> See https://bugs.openjdk.java.net/browse/JDK-8210372
> (also, String::transform)
>
> With best regards,
> Tagir Valeev
Re: RFR: 8180352: Add Stream.toList() method
Hello,
I think the `collect(toList())` is interesting, as the developer
really knows that the internal operation is collect-like.
I say this because there would be another, much more functional
approach, that would be of the form
`stream.map(List::of).reduce(List.empty, List::concat)`,
(if ever the List has been made with monads in minds... (concat does
not exist, and there is no unit for the empty list monad).)
The toList() obfuscates both the list implementation (as the current
utils actually) but also obfuscates the philosophy of the conversion.
As suggested by the previous mail, collect version looks much more
explicit, because it really suggests an aggregate operation and allows
one to use the exact constructor.
What about trying to make the Stream interface *flexible* to users,
instead of adding new functionalities that we could regret later?
Then, as the language usages and the trends evolve, we could really
see which of the "utils" functions are relevant to add.
For example, we could maybe invent a method of the form (just a
sketch, not an actual well thought proposal)
`
default > S wrap(Function, S> wrapper) {
return wrapper.apply(this);
}
`
on Stream interface, in such a way one could use the "natural flow"
of writing while binding its own implementation and, therefore, use
its own shortcuts.
Best regards,
Justin Dekeyser
On Wed, Nov 4, 2020 at 9:59 AM Tagir Valeev wrote:
>
> Hello!
>
> On Wed, Nov 4, 2020 at 2:55 AM Brian Goetz wrote:
> > (In fact, we would be entirely justified to change the behavior of
> > Collectors::toList tomorrow, to match the proposed Stream::toList; the
> > spec was crafted to preserve this option. We probably won't, because
> > there are too many programmers who refuse to read the specification, and
> > have baked in the assumption that it returns an ArrayList, and this
> > would likely just be picking a fight for little good reason, regardless
> > of who is right.)
>
> My experience based on writing Stream code as well as reading Stream
> code written by other developers suggest that one of the most popular
> reasons to modify the resulting list is caused by the need to add a
> special value (or a few of them) to the resulting list. We have
> several options:
> 1. List result =
> Stream.concat(xyz.stream().filter(...).map(...),
> Stream.of("special")).collect(toList());
> Canonical, recommended way, no mutability. However concat is really
> ugly, it breaks the fluent style of stream API calls, it's hard to
> read and people just hate it.
>
> 2. List result =
> xyz.stream().filter(...).map(...).collect(toCollection(ArrayList::new));
> result.add("special");
> Mutable result, but much more readable. Also, according to spec. But
> this ArrayList::new is hard to type and makes the code longer.
>
> 3. List result = xyz.stream().filter(...).map(...).collect(toList());
> result.add("special");
> Shorter and readable! Well, violates the spec but works!
>
> What people really need is an easy and readable way to concatenate
> lists and streams, appending new elements, etc. The JDK doesn't offer
> really great options here, so people often end up with external
> utility methods or libraries.
>
> Something like this would be very welcomed (and would reduce the need
> for mutable lists):
> List result =
> xyz.stream().filter(...).map(...).append("special").collect(toList());
>
> 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.
>
> With best regards,
> Tagir Valeev.
Re: 'Find' method for Iterable
I'm also thinking about something: If `T find()` gets implemented on `Iterable` with the contract that this method always ends, this implies that the amount of elements available in the Iterable is finite, which makes it possible to define a `int size()` by providing a trivial predicate. This would in fact turn `Iterable` to a redundant interface with `Collection`, as the only operations a collection could supply to enrich Iterable are just the add/remove operations, which are all optional by contract. This would sound a bit weird. Iterable will just turn to a readonly collection, and I think this was not the purpose (from a previous long post there were in this newsletter, about splitting the List interface in two interfaces, readonly and write-only). Regards, Justin Dekeyser On Mon, Sep 21, 2020 at 10:31 AM Justin Dekeyser wrote: > > Hi all, > > Correct me if I'm wrong, but isn't the goal of Iterable be used as > argument in a enhanced for-loop, that is: just allow a enhanced > syntax. > (Similarly, AUtoCloseable is what allows the try-with-resource syntax; > Throwable is what allows the throw syntax) > > As such, isn't it out of scope of Iterable to implement this famous find > method? > Since it's scope should just be to allow enhanced for-loop ? > > It's more like a general question in the Java programming language > design actually: is one expected to code with those interfaces in a > business-way, > or implement them to allow a specific syntax ? > > Regards, > > Justin Dekeyser > > On Mon, Sep 21, 2020 at 10:08 AM Michael Kuhlmann wrote: > > > > Hi Nir, > > > > at first I thought "Wow, it would be really cool to have that method in > > Iterable! Why isn't it there already?" > > > > 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. > > > > When some class implements Iterable, it just says "you can iterate over > > my something which I call elements". Nothing more. Now when Iterable > > implements find() by default, then automatically all classes which just > > want to enable users to iterate over elements also tell them that there > > can be something useful found in these elements, which is not > > necessarily the case. > > > > For example, BitSet could immplements Iterable. That doesn't > > make much practical sense, but from the definition of a BitSet it's > > understandable: A BitSet can be seen as a set of integer values, why > > shouldn't someone iterate over them. But now, when you add find() to > > Iterable, it immediately tells users: Hey, you can find integers in me, > > and when you found one, you get it returned. Which is beyond the use > > case of a BitSet. > > > > forEach() is different, because forEach just iterates over the elements > > and nothing more, which is in the scope of an Iterable. > > > > A second argument against adding find() is that such a generic method > > could conflict with more specialized methods in subinterfaces or > > classes. I like the idea of having indexOf(Predicate) in List > > interface, but having both of them would be redundant. > > > > And a third argument is that it can break existing code. An implementor > > of Iterable could already define a find() method, but return the index > > of the element instead of the element itself, or throw some checked > > exception. This code wouldn't compile any more. > > > > So while the idea of having find() in Iterable is great, the arguments > > against are heavier from my point of view. > > > > -Michael > > > > > > On 9/16/20 11:36 PM, Nir Lisker wrote: > > > I don't see a reason to put it Collection when it extends Iterable anyway, > > > and the method just requires iteration. As for execution time, true, it's > > > faster, but Map uses a lot more memory, so it's a tradeoff. For smaller > > > lists, linear time is acceptable. Currently I'm using Maps actually, but I > > > find that when there are many small maps, having many small lists is > > > better > > > for memory and the search time is similar. Additionally, a Map works only > > > for searching by 1 key, but with a Collection/Iterable I can search by any > > > property, and we're not about to use a Map for every property. So, > > > overall, > > > I don't think Map is a competitor in this market. It's also possible to > > > specify that the comple
Re: 'Find' method for Iterable
Hi all,
Correct me if I'm wrong, but isn't the goal of Iterable be used as
argument in a enhanced for-loop, that is: just allow a enhanced
syntax.
(Similarly, AUtoCloseable is what allows the try-with-resource syntax;
Throwable is what allows the throw syntax)
As such, isn't it out of scope of Iterable to implement this famous find method?
Since it's scope should just be to allow enhanced for-loop ?
It's more like a general question in the Java programming language
design actually: is one expected to code with those interfaces in a
business-way,
or implement them to allow a specific syntax ?
Regards,
Justin Dekeyser
On Mon, Sep 21, 2020 at 10:08 AM Michael Kuhlmann wrote:
>
> Hi Nir,
>
> at first I thought "Wow, it would be really cool to have that method in
> Iterable! Why isn't it there already?"
>
> 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.
>
> When some class implements Iterable, it just says "you can iterate over
> my something which I call elements". Nothing more. Now when Iterable
> implements find() by default, then automatically all classes which just
> want to enable users to iterate over elements also tell them that there
> can be something useful found in these elements, which is not
> necessarily the case.
>
> For example, BitSet could immplements Iterable. That doesn't
> make much practical sense, but from the definition of a BitSet it's
> understandable: A BitSet can be seen as a set of integer values, why
> shouldn't someone iterate over them. But now, when you add find() to
> Iterable, it immediately tells users: Hey, you can find integers in me,
> and when you found one, you get it returned. Which is beyond the use
> case of a BitSet.
>
> forEach() is different, because forEach just iterates over the elements
> and nothing more, which is in the scope of an Iterable.
>
> A second argument against adding find() is that such a generic method
> could conflict with more specialized methods in subinterfaces or
> classes. I like the idea of having indexOf(Predicate) in List
> interface, but having both of them would be redundant.
>
> And a third argument is that it can break existing code. An implementor
> of Iterable could already define a find() method, but return the index
> of the element instead of the element itself, or throw some checked
> exception. This code wouldn't compile any more.
>
> So while the idea of having find() in Iterable is great, the arguments
> against are heavier from my point of view.
>
> -Michael
>
>
> On 9/16/20 11:36 PM, Nir Lisker wrote:
> > I don't see a reason to put it Collection when it extends Iterable anyway,
> > and the method just requires iteration. As for execution time, true, it's
> > faster, but Map uses a lot more memory, so it's a tradeoff. For smaller
> > lists, linear time is acceptable. Currently I'm using Maps actually, but I
> > find that when there are many small maps, having many small lists is better
> > for memory and the search time is similar. Additionally, a Map works only
> > for searching by 1 key, but with a Collection/Iterable I can search by any
> > property, and we're not about to use a Map for every property. So, overall,
> > I don't think Map is a competitor in this market. It's also possible to
> > specify that the complexity is linear in an @implNote to avoid surprises.
> >
> > - Nir
> >
> > On Wed, Sep 16, 2020 at 11:59 PM Remi Forax wrote:
> >
> >> - Mail original -
> >>> De: "Nir Lisker"
> >>> À: "core-libs-dev"
> >>> Envoyé: Lundi 14 Septembre 2020 20:56:27
> >>> Objet: 'Find' method for Iterable
> >>
> >>> Hi,
> >>>
> >>> This has probably been brought up at some point. When we need to find an
> >>> item in a collection based on its properties, we can either do it in a
> >>> loop, testing each item, or in a stream with filter and findFirst/Any.
> >>>
> >>> I would think that a method in Iterable be useful, along the lines of:
> >>>
> >>> public Optional find(Predicate condition) {
> >>> Objects.requireNonNull(condition);
> >>> for (T t : this) {
> >>> if (condition.test(t)) {
> >>> return Optional.of(t);
> >>> }
> >>> }
> >>> return Optional.empty();
> >>> }
> >>>
Re: Type inference: bug or feature?
Hello,
Thank you for your input!
Indeed, the reason of such a choice sounds legit and confirms the idea of
having more safety.
I just came with this situation while playing around with Java, and I was
surprised;
But it definitely was an academic example that was not planned for real use
cases! ;-)
Thank you very much,
Have a nice day,
Justin Dekeyser
On Mon, Jul 27, 2020 at 12:55 PM Remi Forax wrote:
> - Mail original -
> > De: "Maurizio Cimadamore"
> > À: "Justin Dekeyser" , "core-libs-dev" <
> core-libs-dev@openjdk.java.net>
> > Envoyé: Lundi 27 Juillet 2020 12:26:40
> > Objet: Re: Type inference: bug or feature?
>
> > CC'ing compiler-dev
> >
> > Hi Justin,
> > the behavior you are observing is normal. For a Java expression to be
> > able to be influenced by type inference it has to be a poly expression
> > (where poly stands for _many_ as in, the same expression can have many
> > types).
> >
> > At the time we did Java 8 we briefly considered making cast expressions
> > part of the poly expression dance (like lambdas, method references,
> > method calls, parens, new creation expression, conditionals and switch
> > expression - see JLS 15.2), but the rule which dictate cast conversion
> > (JLS 5.5) are so complex (as they have to take into account possibility
> > for unchecked cast, etc.) that it felt like touching them was a very
> > risky move, with no clear benefit.
>
> There was another reason :)
>
> The idea behind introducing generics is to get ride of casts because they
> are a hazard at runtime.
> So allowing people to use casts as poly expression goes in the wrong
> direction, add more casts.
>
> Instead of using a cast, it's better to use explicit type arguments,
> TheClass.emptyList()
>
> [...]
>
> >
> > Cheers
> > Maurizio
>
> regards,
> Rémi
>
> >
> > On 26/07/2020 18:22, Justin Dekeyser wrote:
> >> Dear all,
> >>
> >> I'm not sure but I think I've found a bug in Java type inference
> mechanism.
> >> It may also be a feature, so I'll expose the problem to you below; in
> terms
> >> of Integer, Number and List, although you'll quickly realize it will
> work
> >> wrong in any similar situation.
> >>
> >> Let's assume I have
> >>
> >> static List emptyList(Class magnet) {
> >> return Collections.emptyList();
> >> }
> >>
> >> Then the following codes does not compile (for the same reason):
> >>
> >> var x = (List) emptyList(Number.class);
> >> List x = (List) emptyList(Number.class);
> >>
> >> incompatible types: List cannot be converted to List
> >>
> >> however, the following do compile:
> >>
> >> var x = emptyList(Number.class); // inferred to List
> >> List x = emptyList(Number.class); // no mistake here, it's
> Integer
> >> on the left
> >>
> >> Is this the expected behavior? Why does casting operation here interfere
> >> with type inference like this?
> >>
> >> Regards,
> >>
> >> Justin Dekeyser
> >>
> >>
> >>
> >>
> >> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> >> Garanti
> >> sans virus. www.avast.com
> >> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
Re: Type inference: bug or feature?
Dear all,
Okay, thank you very much for the many references you gave me!
Indeed I wasn't aware of this specificity of cast expressions you
mentioned, very interesting !
Sorry for the long email chain, though!
Have a nice day,
Justin Dekeyser
On Mon, Jul 27, 2020 at 12:26 PM Maurizio Cimadamore <
maurizio.cimadam...@oracle.com> wrote:
> CC'ing compiler-dev
>
> Hi Justin,
> the behavior you are observing is normal. For a Java expression to be
> able to be influenced by type inference it has to be a poly expression
> (where poly stands for _many_ as in, the same expression can have many
> types).
>
> At the time we did Java 8 we briefly considered making cast expressions
> part of the poly expression dance (like lambdas, method references,
> method calls, parens, new creation expression, conditionals and switch
> expression - see JLS 15.2), but the rule which dictate cast conversion
> (JLS 5.5) are so complex (as they have to take into account possibility
> for unchecked cast, etc.) that it felt like touching them was a very
> risky move, with no clear benefit.
>
> The behavior you see is caused by the fact that the cast expression acts
> as a "shield" - that is, whenever a method call appears after a cast
> expression (as in your case), the method call is type-checked as if it
> were in isolation, and _then_ the result of type checking is validated
> against the cast. In other words, your example is no different than doing:
>
> var x = (List)(Object)emptyList(Number.class);
>
>
> That is, the emptyList call will see no meaningful target type (just
> Object), so Number will be inferred and a List will be returned,
> which will then be incompatible with the type of the cast expression
> (List).
>
> Your second set of examples, since it does not make use of cast
> expressions, works as expected, as the target type can freely flow
> inside the method call typing, and thus influence the type inference
> result (e.g. the inference engine now sees two constraints, for Integer
> and for Number, and is of course able to pick the "best" one).
>
> Hope this helps.
>
> Cheers
> Maurizio
>
> On 26/07/2020 18:22, Justin Dekeyser wrote:
> > Dear all,
> >
> > I'm not sure but I think I've found a bug in Java type inference
> mechanism.
> > It may also be a feature, so I'll expose the problem to you below; in
> terms
> > of Integer, Number and List, although you'll quickly realize it will work
> > wrong in any similar situation.
> >
> > Let's assume I have
> >
> > static List emptyList(Class magnet) {
> > return Collections.emptyList();
> > }
> >
> > Then the following codes does not compile (for the same reason):
> >
> > var x = (List) emptyList(Number.class);
> > List x = (List) emptyList(Number.class);
> >
> > incompatible types: List cannot be converted to List
> >
> > however, the following do compile:
> >
> > var x = emptyList(Number.class); // inferred to List
> > List x = emptyList(Number.class); // no mistake here, it's
> Integer
> > on the left
> >
> > Is this the expected behavior? Why does casting operation here interfere
> > with type inference like this?
> >
> > Regards,
> >
> > Justin Dekeyser
> >
> >
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > Garanti
> > sans virus. www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
Re: Type inference: bug or feature?
Hello, Again, thanks for the prompt response! Well, I'm not really sure about the answer but, to my understanding, if this: List x = emptyList(Number.class); compiles correctly (thus U inferred as Number, V inferred as Integer as expected), then why this List x = (List) emptyList(Number.class); does not compile ? (with explicit or var-typing) On the other hand, the following code var x = (Function) x -> x; compile with no error, hence in this case, casting does help in type inference. I really feel that, although a bit "over complicated", there is something that I either really don't get, or something else :/ Regards, Justin Dekeyser On Mon, Jul 27, 2020 at 10:21 AM Florian Weimer wrote: > * Justin Dekeyser: > > > Nevertheless, the point was not really about list stuffs, and is not > > related to the lack of co/contra variance. > > > You may replace List with any other generic class Foo and Integer > > and Number with any other class satisfying the same inheritance > > relations. > > Ahh, well, but why are such casts useful? The results will be wrong in > pretty much every case. Their correctness cannot be checked at run > time, either. > > Thanks, > Florian > >
Re: Type inference: bug or feature?
Hello, Thanks for the answer. Nevertheless, the point was not really about list stuffs, and is not related to the lack of co/contra variance. You may replace List with any other generic class Foo and Integer and Number with any other class satisfying the same inheritance relations. The behavior is really about casting, which prevents type inference to work "as one would expect". This is even weirder because, in case of lambda expressions, casting does help in desambiguising the type. So on the one side, we have a casting operation that helps in type inference, on the other side, we have a casting operation that prevents some inference. I'm really not sure this is no bug :/ Regards, Justin Dekeyser On Mon, Jul 27, 2020 at 9:43 AM Florian Weimer wrote: > * Justin Dekeyser: > > > Then the following codes does not compile (for the same reason): > > > > var x = (List) emptyList(Number.class); > > List x = (List) emptyList(Number.class); > > > > incompatible types: List cannot be converted to List > > > > however, the following do compile: > > > > var x = emptyList(Number.class); // inferred to List > > List x = emptyList(Number.class); // no mistake here, it's > Integer > > on the left > > > > Is this the expected behavior? Why does casting operation here interfere > > with type inference like this? > > emptyList() is special, it only works this way because the returned list > is always empty, so that the element type does not matter. For any > other list-returning function, the types List and List > are not interchangeable because for each type, there are operations > which are not valid for the other. That's why we often need wildcards > once type hierarchies are involved (List or > List, depending on context). > > A somewhat similar case is functions which do not return (normally). > They too can have a very general generic type which does not depend on > function arguments. > > Thanks, > Florian > >
Type inference: bug or feature?
Dear all,
I'm not sure but I think I've found a bug in Java type inference mechanism.
It may also be a feature, so I'll expose the problem to you below; in terms
of Integer, Number and List, although you'll quickly realize it will work
wrong in any similar situation.
Let's assume I have
static List emptyList(Class magnet) {
return Collections.emptyList();
}
Then the following codes does not compile (for the same reason):
var x = (List) emptyList(Number.class);
List x = (List) emptyList(Number.class);
incompatible types: List cannot be converted to List
however, the following do compile:
var x = emptyList(Number.class); // inferred to List
List x = emptyList(Number.class); // no mistake here, it's Integer
on the left
Is this the expected behavior? Why does casting operation here interfere
with type inference like this?
Regards,
Justin Dekeyser
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Garanti
sans virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Re: Feature Request
Hello, Wouldn't that be too dangerous, in the sense that it makes us lose control over how the String are actually constructed and aggregated together? Aside from that, what kind of interpolation are you looking for, and how the String.format utility does not meet your needs? Regards, D.J. On Tue, Jul 21, 2020 at 7:08 PM Jessica wrote: > Hi, > > I would like to strongly request Java have the ability to do string > interpolation. > It is such a great convenience and allows for faster, more efficient coding > that is easier to read. > > Is this feature on the roadmap in the foreseeable future? > > Thank you! > > Jessica Risavi > > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > Virus-free. > www.avg.com > < > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >
Re: Was functional-Try already discussed?
I realized it may still not be clear! Sorry,
My dream Try would be something like this:
```
import static java.util.Try.on;
import static java.util.Try.safe;
private Bar convert (Foo foo) throws ConversionException { ... }
Stream foos;
Stream bars =
foos.map(on(ConversionException.class)::of).map(safe(this::convert)).filter(Try::notInFailure).map(Try::get);
```
This is the algebra I would like to be able to write down! Basically,
Try.on would return a monad of Try< . , ConversionException>, while the
Try.safe method sanitizes a method:
```
@FunctionalInterface interface TryFunction { V
apply(U args) throws E; }
Function> safe (TryFunction f) { ... }
```
The Try could be enriched with many interpolability facilities, but its
essence would be to catch the provided exception.
Best regards,
Justin Dekeyser
On Fri, May 8, 2020 at 1:23 AM Justin Dekeyser
wrote:
> Dear Dmytro,
>
> Thank you very much for the time you have spent answering my email.
> I am sorry if I was not clear in my previous sending. I will try to
> elaborate.
>
> In my various situations, I find people that are convinced that checked
> exceptions are too hard to manage, especially beacause it does not fit well
> with streams and Optional.
>
> I think a Try class, as usually defined, may be a good utilitary class to
> have in the java.utils library, in the same way Optional does.
>
> In my opinion, the covered feature is an enhancement, fills a gap in
> functional style flow suggested by stream and optional, is business
> agnostic, technology independant, figths against the anti pattern people
> adopt by defining unchecked exceptions, so for all these reasons, I think
> one can propose a solution as standard.
>
> Was the Try already discussed somewhere? What does Optional conceptually
> brings, that Try could not?
>
> Best regards,
>
> Justin Dekeyser
>
> On Thursday, May 7, 2020, dmytro sheyko
> wrote:
>
>> Hi Justin,
>>
>> This is not quite clear what exactly you are talking about. In any case
>> why do you think it should be a part of OpenJDK? Can't it be just a
>> separate library?
>>
>> Regards,
>> Dmytro
>>
>> On Wed, May 6, 2020 at 8:31 AM Justin Dekeyser
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I am new to the OpenJDK community and I'm using Java fora small decade
>>> now,
>>> first as a hobby, then in my academic studies and my PhD in maths, and
>>> now
>>> as a professional developer in IT companies. I'm quite active on forum to
>>> help people, I've helped teaching students in the university, I read a
>>> lot
>>> of posts on blogs, and so many times I'm facing people having trouble
>>> with
>>> checked exceptions.
>>>
>>> The situation in my current job makes clarifies what I mean. People
>>> usually
>>> like declaring their own exception super class as "BusinessException",
>>> then
>>> deriving it in many subclasses to describe more accurate failure reasons.
>>> The problem they face is that when they declare their class as *checked
>>> Exception*, they cannot use the mechanism of Optional and Stream, for an
>>> obvious reason. Usually they prefer Optional and Stream, so they end up
>>> by
>>> subclassing RuntimeException.
>>>
>>> I find it so sad because, when interfacing services, you often forget
>>> about
>>> declaring those unchecked exceptions, and the client is not aware of
>>> what's
>>> happening! I think you loose all the benefit of the exception mechanism
>>> in
>>> Java here for a very bad reason.
>>>
>>> In my job I finally rectified (partially, because the code base is huge)
>>> the situation by implementing a "functional" Try in the same spirit than
>>> the Optional. People are quite happy with it. I can invest more time in
>>> its
>>> development but I think this small library could help more people about
>>> turning their exception in something clean again. So maybe it could be
>>> useful for the whole community. (I already discussed it with my boss,
>>> there
>>> will be no copyright problem.)
>>>
>>> There exists similar projects around the world (in the Vavr lib for
>>> example) and Scala offers this as a basic feature, which basically means
>>> that people could appreciate the enhancement!
>>>
>>> I am wondering if the Try interface would be interesting for OpenJDK, if
>>> they have been discussions about it, and what were the decisions about
>>> such
>>> a library? In my opinion, it may be a good complement to the Optional and
>>> the Stream interfaces to allow a functional style while keeping this cool
>>> feature of checked exceptions.
>>>
>>> Best regards,
>>>
>>> Justin Dekeyser
>>>
>>
Was functional-Try already discussed?
Hi everyone, I am new to the OpenJDK community and I'm using Java fora small decade now, first as a hobby, then in my academic studies and my PhD in maths, and now as a professional developer in IT companies. I'm quite active on forum to help people, I've helped teaching students in the university, I read a lot of posts on blogs, and so many times I'm facing people having trouble with checked exceptions. The situation in my current job makes clarifies what I mean. People usually like declaring their own exception super class as "BusinessException", then deriving it in many subclasses to describe more accurate failure reasons. The problem they face is that when they declare their class as *checked Exception*, they cannot use the mechanism of Optional and Stream, for an obvious reason. Usually they prefer Optional and Stream, so they end up by subclassing RuntimeException. I find it so sad because, when interfacing services, you often forget about declaring those unchecked exceptions, and the client is not aware of what's happening! I think you loose all the benefit of the exception mechanism in Java here for a very bad reason. In my job I finally rectified (partially, because the code base is huge) the situation by implementing a "functional" Try in the same spirit than the Optional. People are quite happy with it. I can invest more time in its development but I think this small library could help more people about turning their exception in something clean again. So maybe it could be useful for the whole community. (I already discussed it with my boss, there will be no copyright problem.) There exists similar projects around the world (in the Vavr lib for example) and Scala offers this as a basic feature, which basically means that people could appreciate the enhancement! I am wondering if the Try interface would be interesting for OpenJDK, if they have been discussions about it, and what were the decisions about such a library? In my opinion, it may be a good complement to the Optional and the Stream interfaces to allow a functional style while keeping this cool feature of checked exceptions. Best regards, Justin Dekeyser
