Lambda Serialization
by William Burns
I wanted to propose a pretty simple way of making the lambdas serializable
by default that I stumbled upon while working on another issue.
I noticed that in the method resolution of the compiler it does some nice
things [1]. To be more specific when you have 2 methods with the same name
but vary by argument types, it will attempt to pick the most "specific"
one. Specific in this case you can think of if I can cast one argument
type to the other but it can't be cast to this type, then this one is most
specific.
Here is an example, given the following class
interface SerializableFunction<T, R> extends Serializable, Function<T, R>
The stream interface already defines:
Stream map(Function<? super T, ? extends R> mapper);
But we could add this to the CacheStream interface
CacheStream map(SerializableFunction<? super T, ? extends R> mapper);
In this case you have 2 different map methods accessible from your
CacheStream instance. When passing a lambda the Java compiler will
automatically choose the most specific one (in this case the
SerializableFunction one since Function can't be cast to
SerializableFunction). This will then make the lambda automatically
Serializable. In this way nothing special has to be done (ie. explicit
cast) to make the instance Serializable.
This allows anyone using our Cache interface to immediately get lambdas
that are Serializable when using Streams.
The main problem however would be ambiguity because the Serialization would
only be applied assuming you are using a defined class of CacheStream etc.
Also this means there are 2 methods (but that seems fine to me), so it
could cause a bit of confusion. The non serialization method is still
helpful if people want to their own Externalizer, since their
implementation doesn't have to implement Serializable then.
What do you guys think? It seems like a decent compromise to me.
- Will
[1]
https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5
10 years, 1 month
Shade source jar issue?
by Galder Zamarreño
Hi guys,
I've been trying to test out a embedded shaded jar snapshot but I'm having issues with discrepancies between jar file and source file.
It appears that the source file is not updated, e.g.
If I take the jar, expand it and grep, I see this:
$ javap org.infinispan.CacheStream | grep collect
public abstract <R1, A> R1 collect(java.util.stream.Collector<? super R, A, R1>);
public abstract <R1> R1 collect(org.infinispan.util.SerializableSupplier<R1>, org.infinispan.util.SerializableBiConsumer<R1, ? super R>, org.infinispan.util.SerializableBiConsumer<R1, R1>);
When I look at the source jar, I see:
$ grep collect ./org/infinispan/CacheStream.java
...
<R1, A> R1 collect(Collector<? super R, A, R1> collector);
Are you aware of any issues with shade source jars?
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
10 years, 1 month
HotRod exec operation tight coupling with JBoss Marshaller
by Galder Zamarreño
Hi all,
While implement `exec` operation for the JS client, I've encountered an issue with how the exec parameters and return types are marshalled.
The essence of the problem is that the server marshalls these objects instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good.
I'm not sure this would have been unavoidable due to the characteristics of `exec` but I wanted to see if we can find a good way to solve or get around this issue. Long term, we need better encoding handling both for incoming and returning types, but the question is whether we can find a way to better solve this until then. Here are some options:
- For the C++ client, Vittorio has part implemented the JBoss Marshaller format [1], but I'm kinda reluctant to go down this path since that creates a lot of work for us as the number of types that can be discovered in a JBoss Marshaller format byte array are quite considerable [2]. We're bound to miss one of those and since clients could execute any script, the chances are high IMO...
- An alternative would be for the JS/C++ clients to only support exec when the marshaller is one that enables compatibility mode. The idea here is that for compatibility mode to work, all clients involved are going to be set up with a marshaller that can work for all of them. Working on such marshaller is time better spent than on implementing the JBoss Marshaller format. We had a separate discussion on this topic in another dev thread...
Any other ideas someone might have?
Cheers,
[1] https://github.com/infinispan/cpp-client/blob/master/include/infinispan/h...
[2] https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src...
--
Galder Zamarreño
Infinispan, Red Hat
10 years, 1 month
Early Access builds of JDK 9 b107 & JDK 9 with Project Jigsaw b106 (#4540) are available on java.net
by Rory O'Donnell
Hi Galder,
Early Access b107 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://download.java.net/java/jdk9/changes/jdk-9+107.html>.
Among other fixes , the following are also included:
* Update class file version to 53 for JDK-9, more info here
<http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8148785>
* Add support for ES6 collections , more info here
<http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8147558>
Early Access b106 <https://jdk9.java.net/jigsaw/> (#4540) for JDK 9 with
Project Jigsaw is available on java.net.
The March 2016 Quality Outreach Report is posted on here,
<https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+Mar...>
thanks again to those who
found & logged bugs against Early Access builds.
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 1 month
