http://central.maven.org/maven2/org/danekja/jdk-serializable-functional/1.8.1/
@Emond: do you want to make the changes ? Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Nov 2, 2016 at 4:47 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > > On Mon, Oct 31, 2016 at 10:15 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > >> >> On Mon, Oct 31, 2016 at 5:11 PM, Emond Papegaaij < >> emond.papega...@topicus.nl> wrote: >> >>> On maandag 31 oktober 2016 16:38:48 CET Martin Grigorov wrote: >>> > Hi Emond, >>> > >>> > On Mon, Oct 31, 2016 at 4:28 PM, Emond Papegaaij < >>> emond.papega...@topicus.nl >>> > > wrote: >>> > > >>> > > Hi, >>> > > >>> > > I'm not sure about the duplicate functional interfaces in >>> > > org.apache.wicket.lambda. The current solution ties these interfaces >>> to >>> > > Wicket, making it impossible to share function-libraries between >>> wicket >>> > > and >>> > > non-wicket code. >>> > > >>> > > For example this method returns a function that prints a time with >>> seconds >>> > > in >>> > > >>> > > the given locale: >>> > > public static WicketFunction<Instant, String> >>> > > >>> > > timeWithSeconds(final Supplier<Locale> localeSupplier) { ... } >>> > >>> > I am not sure this is true. >>> > The important thing is the Wicket APIs to use WicketXyz. This tells the >>> > compiler to use/create a java.lang.invoke.SerializedLambda. >>> > You can pass any kind of Xyz as an argument and it will work just fine. >>> >>> Functional interfaces are just normal interfaces. A Function is not a >>> WicketFunction and a TopicusFunction is not a WicketFunction either. You >>> can >>> create a serializable method reference to the apply method, but that's >>> just >>> ugly. A method taking a WicketFunction will not accept a Function nor a >>> TopicusFunction. This is something we ran into when converting Guava >>> code to >>> java.util interfaces. >>> >> >> OK. I see what you mean. >> I've found https://github.com/danekja/jdk-serializable-functional but it >> seems it is not at Maven Central. I've created an issue to ask the author. >> > > https://github.com/danekja/jdk-serializable-functional/ > issues/1#issuecomment-257903712 > Happy customer! > > >> >> >>> >>> > >>> > > The current WicketFunction is tied to wicket, so I cannot place this >>> > > function >>> > > in a shared library. When changing the type to java.util.Function, I >>> > > cannot >>> > > use it on pages, because it is not serializable. The only option that >>> > > remains >>> > > >>> > > is changing it to and constructing functions on the spot: >>> > > public static String timeWithSeconds(Instant instant, Locale >>> locale) { >>> > > >>> > > ... } >>> > > >>> > > I propose to move the classes to a standalone maven module, rename >>> them to >>> > > SerializableFunction (etc.) and let them implement Serializable (not >>> > > IClusterable). Maybe even change the package to something non-wicket. >>> > > >>> > > Also, the current interfaces do not override the default methods >>> provided >>> > > by >>> > > the super-interfaces (such as compose and andThen). Using the >>> methods on >>> > > the >>> > > current classes will give non-serializable versions of the >>> interfaces. >>> > > >>> > > Finally, many commonly used interfaces are missing, such as: >>> Runnable, >>> > > Predicate, BiPredicate and more. Perhaps we should duplicate all >>> > > FunctionalInterfaces, maybe only the ones most often used. >>> > >>> > I am not sure this is even needed and most definitely we cannot provide >>> > serializable version for all interfaces out there. >>> >>> At Topicus we have the ones provided by Wicket, plus Runnable, Predicate >>> and >>> BiPredicate. That seems to be fine for most cases. It is important to >>> provide >>> all default methode though. Otherwise SerializablePredicate.negate() no >>> longer >>> is serializable, and that's not what you would expect. >>> >>> > > In all, I propose to create a simple library that provides many >>> > > serializable >>> > > versions of functional interfaces. I think such a library does not >>> belong >>> > > in >>> > > Wicket, but that's the best we can do. Mayby the guys from commons >>> are >>> > > willing >>> > > to take the code. >>> > > >>> > > What do you think? >>> > > >>> > > Best regards, >>> > > Emond >>> > > >>> > > On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote: >>> > > > Hi, >>> > > > >>> > > > What other improvements do we need in 8.x/master before promoting >>> it to >>> > > > 8.0.0 final ? >>> > > > >>> > > > At https://cwiki.apache.org/confluence/display/WICKET/ >>> > > >>> > > Ideas+for+Wicket+8.0 >>> > > >>> > > > we still have: >>> > > > >>> > > > - new DateTime APIs for wicket-datetime *WICKET-6105 >>> > > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give >>> this >>> > > >>> > > one >>> > > >>> > > > more try but the problem is that I don't believe this is the >>> proper way >>> > > >>> > > and >>> > > >>> > > > this demotivates me. >>> > > > If someone else wants to give it a try - please assign it to >>> yourself! >>> > > > >>> > > > - Better SEO for stateful pages - the only way I see this is by >>> using >>> > > > ServiceWorker to add the pageId as a request header to all requests >>> > > >>> > > (normal >>> > > >>> > > > & Ajax) >>> > > > >>> > > > >>> > > > Recently I wondered whether Redux.js could be in use for Wicket. >>> > > > I don't have much experience with it, but both React and AngularJs >>> > > > communities use it to manage the state for their components. >>> > > > There are some Java impls, even a standard is coming: >>> > > > https://github.com/jvm-redux/jvm-redux-api >>> > > > >>> > > > What else ? >>> > > > >>> > > > Martin Grigorov >>> > > > Wicket Training and Consulting >>> > > > https://twitter.com/mtgrigorov >>> >>> >>> >> >
