I want to modify list of already created objects in stream. I realized three approaches that may do that, but I not sure about their performance and possible downsize.
Return same object - not waste of time to creating new object, but object is mutable
Create new object - parameter is not modified, but for huge object creation is time consuming
Modify parameter - can only use ForEach, no parallel usage
Code below code with explaining comments.
public class Test {
public static void main(String[] args) {
//Already created objects
List<Foo> foos0 = Arrays.asList(new Foo("A"));
//However I need to apply some modification on them, that is dependent on themselves
//1. Returning same object
List<Foo> foos1 = foos0.stream().map(Test::modifyValueByReturningSameObject).collect(Collectors.toList());
//2. Creating new object
List<Foo> foos2 = foos0.stream().map(Test::modifyValueByCreatingNewObject).collect(Collectors.toList());
//3. Modifying param
foos0.stream().forEach(Test::modifyValueByModifyingParam);
}
//Lets imagine that all methods below are somehow dependent on param Foo
static Foo modifyValueByReturningSameObject(Foo foo) {
foo.setValue("fieldValueDependentOnParamFoo");
return foo;
}
static Foo modifyValueByCreatingNewObject(Foo foo) {
Foo newFoo = new Foo("fieldValueDependentOnParamFoo");
return newFoo;
}
static void modifyValueByModifyingParam(Foo foo) {
foo.setValue("fieldValueDependentOnParamFoo");
return;
}
}
public class Foo {
public String value;
public Foo(String value) {
this.value = value;
}
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
}
So the question is which is the most stream approach?
EDIT:
By stream approach I mean, that the most advantages in sense of performence.
EDIT2:
1. Which is functional approach?
2. Which is best in sense of performance?
The javadoc states that Streams should avoid side effects :
Side-effects in behavioral parameters to stream operations are, in general, discouraged, as they can often lead to unwitting violations of the statelessness requirement, as well as other thread-safety hazards.
So, you should prefer the solution where you create new objects instead of modifying existing ones.
The different aproaches will in your case most likely result in no difference regarding performance.
Reason: optimization. Java will not really create new classes and will use direct access to fields. It might(and will if analysis sugests it) even skip a whole chain of calls and replace it by a precalculated value. Java runtime even utilizes a profiler to optimize and find hotspots...
Also: Regarding performance it is in general(particular cases may differ) more important to create a simple structure and help the runtime to make the right assumptions.
So if you hide what you are doing in unesseary manual "optimization", that hides optimization posibilities(lots of branches/decisions, unnecessary pinning, chain of "unknown" methods ...) from the runtime you might end up with a slower result.
For clarity and sideffects(see also other answer) I rather use the version that creates new instances.
Related
What sort of optimizations would Java Runtime perform on the follow snippet of code? The bytecode doesn't reveal any optimization however I feel that Java should take the last value of the for loop without running the entire for loop since String is a rudimentary Java class.
NOTE. this question was asked on a class test; however, I couldn't provide enough evidence to back my claim.
public class Main {
public static void main(String[] args) {
String str = null;
for (long i = 0; i < 10000000000L; i++) {
str = new String("T");
}
System.out.println(str);
}
}
While I can't speak to exactly what the jit compiler is doing, the optimization you are asking it to do (to determine that it is safe to skip the loop body entirely) is actually extremely difficult to do, and so I highly doubt it it is done. This is true regardless of String being a "rudimentary Java class".
To understand better, first let's assume that instead of String, we are creating instances of an arbitrary class Foo. It would only be safe to skip the creation of all those Foo objects if we knew two things: that calling new Foo() didn't have any observable side effects; and that no references to Foo "escaped" the loop body.
An observable side effect would be something like setting the value of a static member (e.g. if the Foo class kept a static count of all the times Foo() had been called). An example of a reference escaping would be if the this variable inside of Foo() was passed somewhere else.
Note that it isn't enough to just look at Foo(), you need to look at Foo's superclass' constructor (and all the way up the chain to Object). And then you need to look at all the code that gets executed upon initialization of each of those objects. And then look at all the code that gets called by that code. That would be a tremendous amount of analysis to do "just-in-time".
public class Foo extends Bazz{
static int count = 0;
public Foo(){
// Implicit call to Bazz() has side effect
count++; // side effect
Bazz.onNewFoo(this); // reference escaping
}
Bazz bazz = new Bazz(); // side effect
{
Bazz.onNewBazz(this.bazz); // reference escaping
}
}
class Bazz{
static int count = 0;
static List<Foo> fooList = new LinkedList<>();
static List<Bazz> bazzList = new LinkedList<>();
static void onNewFoo(Foo foo){
fooList.add(foo);
}
static void onNewBazz(Bazz bazz){
bazzList.add(bazz);
}
public Bazz(){
count++;
}
}
You might think we should just let javac do this analysis and optimization for us. The problem with that is, that there is no way to guarantee that the version of Foo() that was on the classpath at compile-time will be the same as that which is on the classpath at run-time. (Which is a very valuable feature of Java - it allows me to move my application from Glassfish to Tomcat without recompiling). So we can't trust analysis done at compile-time.
Finally, realize that String is no different from Foo. We'd still need to run that analysis, and there is no way to do that analysis in advance (which I why I can upgrade my JRE without recompiling my apps)
If an object reference is passed to a method, is it possible to make the object "Read Only" to the method?
Not strictly speaking. That is, a reference that can mutate an object can not be turned into a reference that can not mutate an object. Also, there is not way to express that a type is immutable or mutable, other than using conventions.
The only feature that ensure some form of immutability would be final fields - once written they can not be modified.
That said, there are ways to design classes so that unwanted mutation are prevented. Here are some techniques:
Defensive Copying. Pass a copy of the object, so that if it is mutated it doesn't break your internal invariants.
Use access modifiers and/or interface to expose only read-only methods. You can use access modifieres (public/private/protected), possibly combined with interface, so that only certain methods are visible to the other object. If the methods that are exposed are read-only by nature, you are safe.
Make your object immutable by default. Any operation on the object returns actually a copy of the object.
Also, note that the API in the SDK have sometimes methods that return an immutable version of an object, e.g. Collections.unmodifiableList. An attempt to mutate an immutable list will throw an exception. This does not enforce immutability statically (at compile-time with the static type system), but is is a cheap and effective way to enforce it dynamically (at run-time).
There has been many research proposals of Java extension to better control of aliasing, and accessibility. For instance, addition of a readonly keyword. None of them is as far as I know planned for inclusion in future version of Java. You can have a look at these pointers if you're interested:
Why We Should Not Add ''Read-Only'' to Java (yet) -- it lists and compare most of the proposals
The Checker Framework: Custom pluggable types for Java -- a non intrusive way to extend the type system, notably with immutable types.
The Checker Framework is very interesting. In the Checker Framework, look at Generic Universe Types checker, IGJ immutability checker, and Javari immutability checker. The framework works using annotations, so it is not intrusive.
No, not without decorating, compositing, cloning, etc.
There's no general mechanism for that. You'll need to write special-case code to achieve it, like writing an immutable wrapper (see Collections.unmodifiableList).
You could achieve a similar thing in most cases by cloning the Object as the first statement of the method, such as this...
public void readOnlyMethod(Object test){
test = test.clone();
// other code here
}
So if you called readOnlyMethod() and pass in any Object, a clone of the Object will be taken. The clone uses the same name as the parameter of the method, so there's no risk of accidentally changing the original Object.
No. But you could try to clone the object before passing it, so any changes made by the method won't affect the original object.
making it implement a interface which has only read only methods (no setter methods) this gives a copy of an object (road-only copy) and returning the read only instance of interface instead of returning the instance of an object itself
You could define all parameters of the objects as final but that makes the object read only to everyone.
I believe your real question is about avoiding escape references.
As pointed out in some answers to extract an Interface from class and expose only get methods. It will prevent modification by accident but it is again not a foolproof solution to avoid above problem.
Consider below example:
Customer.java:
public class Customer implements CustomerReadOnly {
private String name;
private ArrayList<String> list;
public Customer(String name) {
this.name=name;
this.list = new ArrayList<>();
this.list.add("First");
this.list.add("Second");
}
#Override
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
#Override
public ArrayList<String> getList() {
return list;
}
public void setList(ArrayList<String> list) {
this.list = list;
}
}
CustomerReadOnly.java:
public interface CustomerReadOnly {
String getName();
ArrayList<String> getList();
}
Main.java:
public class Test {
public static void main(String[] args) {
CustomerReadOnly c1 = new Customer("John");
System.out.println("printing list of class before modification");
for(String s : c1.getList()) {
System.out.println(s);
}
ArrayList<String> list = c1.getList();
list.set(0, "Not first");
System.out.println("printing list created here");
for(String s : list) {
System.out.println(s);
}
System.out.println("printing list of class after modification");
for(String s : c1.getList()) {
System.out.println(s);
}
}
}
Ouput:
printing list of class before modification
First
Second
printing list created here
Not first
Second
printing list of class after modification
Not first
Second
So, as you can see extracting interface and exposing only get methods works only if you don't have any mutable member variable.
If you have a collection as a member variable whose reference you don't want to get escape from class, you can use Collections.unmodifiableList() as pointed out in ewernli's answer.
With this no external code can modify the underlying collection and your data is fully read only.
But again when it comes to custom objects for doing the same, I am aware of the Interface method only as well which can prevent modification by accident but not sure about the foolproof way to avoid reference escape.
Depending on where you want the rule enforced. If you are working collaboratively on a project, use final with a comment telling the next person they are not meant to modify this value. Otherwise wouldn't you simply write the method to not touch the object?
public static void main(String[] args) {
cantTouchThis("Cant touch this");
}
/**
*
* #param value - break it down
*/
public static void cantTouchThis(final String value) {
System.out.println("Value: " + value);
value = "Nah nah nah nah"; //Compile time error
}
So specifically to this method, the value will never be written to, and it is enforced at compile time making the solution extremely robust. Outside the scope of this method, the object remains unaltered without having to create any sort of wrapper.
private boolean isExecuteWriteQueue = false;
public boolean isWriting(){
final boolean b = isExecuteWriteQueue;
return b;
}
Expanding on ewernli's answer...
If you own the classes, you can use read-only interfaces so that methods using a read-only reference of the object can only get read-only copies of the children; while the main class returns the writable versions.
example
public interface ReadOnlyA {
public ReadOnlyA getA();
}
public class A implements ReadOnlyA {
#Override
public A getA() {
return this;
}
public static void main(String[] cheese) {
ReadOnlyA test= new A();
ReadOnlyA b1 = test.getA();
A b2 = test.getA(); //compile error
}
}
If you don't own the classes, you could extend the class, overriding the setters to throw an error or no-op, and use separate setters. This would effectively make the base class reference the read-only one, however this can easily lead to confusion and hard to understand bugs, so make sure it is well documented.
I've never had the chance to play much with generics before (as in writing classes that are generics), but now the need arises, and I've come across some confusion.
There's this interface, that is meant to be a wrapper of something. The implementations are not collections, so, every instance has access only to one something.
public interface Resource<T> {
// Expected operations:
void write(ResourceState state);
ResourceState read();
}
As implementations, I expect to have an ExclusiveResource<T>, and a ShareableResource<T>, that differ mainly/only in the locking scheme used (regular lock, and read-write lock, respectively).
As to how the read and write are performed, I'm planning on using the Strategy pattern.
For instance, I might have
// This would implement a Strategy<File>.
FileStrategy fs = new FileStrategy();
Resource<File> r = new ExclusiveResource<File>(fs);
Now, I've also got some sort of collection of these resources, say, a resource pool.
I'd like to map a key to each resource, in the resource pool, and I'd like to add, retrieve and remove resources, but I'm not sure how to declare the map and the methods. I've tried the following:
public class ResourcePool {
// instance variables
private final Map<String, Resource<?>> map;
/** Empty constructor of objects of class ResourcePool. */
public ResourcePool() {
map = new HashMap<String, Resource<?>>();
}
/** */
public Resource<?> get(String s) {
return map.get(s);
}
/** */
public void add(String s, Resource<?> r) {
map.put(s, r);
}
// ...
}
This does not seem to be the most appropriate way to do it, and, quoting Josh Bloch, on Effective Java Reloaded:
User should not have to think about wildcards to use your API.
I've tested this code with the following method:
public static void test() {
ResourcePool rp = new ResourcePool();
Resource<String> r1 = new ShareableResource<>("test");
Resource<Integer> r2 = new ShareableResource<>(1);
Resource<List<String>> r3 = new ShareableResource<>(
Arrays.asList(new String[]{"1", "2"})
);
// These are all ok.
rp.add("1", r1);
rp.add("2", r2);
rp.add("3", r3);
// This results in a compiler error (incompatible types).
Resource<String> g1 = rp.get("1");
// This results in a compiler warning (unsafe operation).
Resource<String> g2 = (Resource<String>) rp.get("1");
}
I don't like it, when the code compiles with warnings. Makes me feel guilty, and seems to be a hint at bad coding.
So, my question is how should I handle this situation.
Is this the right way to do what I'm trying to do?
Can this be done in such a way that there are no unsafe operations?
I don't think there's any way to avoid unchecked casts using your design. That said, you can avoid having to do a cast every time you retrieve a Resource:
#SuppressWarnings("unchecked")
public <T> Resource<T> get(String s, Class<T> c) {
return (Resource<T>) map.get(s);
}
When you want to retrieve a Resource, you pass in the desired class, like so:
Resource<String> g1 = rp.get("1", String.class);
You should be careful with this design, though, since there will be no runtime guarantee that the returned Resource is actually a Resource<String>.
You could create different collections for each type of resource you want, and make ResourcePool generic also:
ResourcePool<String> stringpool = new ResourcePool<String>();
ResourcePool<Integer> intpool = new ResourcePool<Integer>();
This would give you the benefits of compile-time checking on your types. And it seems that you know what type you want whenever you get something out of the ResourcePool, so you can select the appropriate collection.
I have to implement a class whose instances have a bidirectional relation to each other. For example I have the class FooBar which should offer the method sameAs(FooBar x) and maintain a Set for each instances containing its equivalent instances. So if I call foo.sameAs(bar), the Set in foo should contain bar and vice versa. Invoking bar.sameAs(foo) doesn't work, of course.
For clarifiction: the instances of this class are only semantically equal. equals should still return false.
The solutions I've come up with is either to implement a private method internalSameAs(FooBar x) which is invoked from sameAs(FooBar x) or to use a static method sameAs(FooBar x, FooBar y).
Solution 1:
class FooBar {
Set<FooBar> sameAs = new HashSet<FooBar>();
public void sameAs(FooBar x) {
this.internalSameAs(x);
x.internalSameAs(this);
}
public void internalSameAs(FooBar x) {
sameAs.add(x);
}
}
Solution 2:
class FooBar {
Set<FooBar> sameAs = new HashSet<FooBar>();
public static void sameAs(FooBar x, FooBar y) {
x.sameAs.add(y);
y.sameAs.add(x);
}
}
Which one would you prefer and why? Or is there another way I didn't think about?
The naming you've used is confusing. sameAs sounds as though it's a test which should return a boolean, but from your code it seems it would be more appropriately named declareSameAs. When you call foo.sameAs(bar), you're declaring that foo and bar are the same, not doing a test, correct?
The problem is that with your code you can declare
x.sameAs(y);
y.sameAs(z);
but it won't be the case that x is the same as z, which is presumably not what you want (and if it is what you want, you definitely need to change the method name).
It seems to me you want to divide your instances into sets, and have each instance keep a reference to the set it's in (not to a separate set internal to the instance). When you make a new declaration that two instances are the same, you need to combine the sets, and ensure all affected instances have a reference to the combined set.
are you flexible with the data structures to be used? If so you could use a Multimap (from Guava Collections) that is static amongst all the instances of the class FooBar. In that Multimap you can have the keys as FooBar references (or a unique id if you have one) and the values would be the references (or id.s) of the FooBars that have the sameAs relation.
Maybe there's a different way: sameAs sounds pretty similiar to equals. If we do not need equals for something else, then I'd simply implement the equals method on FooBar so that we simply do a
if (foo.equals(bar))
System.out.println("We're equal (aka: 'equivalent/the same')");
In this case, we do not need any set - just a rule to determine, if two instances are equal.
You could store the sameness information in a separate datastructure outside of those classes. A central map could do the job:
HashMap<FooBar, Set<FooBar>> sameFooBars;
If you have "same" objects, simply add them to the map:
public static void addSameObjects(FooBar foo1, FooBar foo2) {
Set<FooBar> set = getMap().get(foo1);
if (set == null) {
set = new HashSet<FooBar>();
getMap().put(foo1, set);
}
set.add(foo2);
// serious implementation avoid code duplication...
set = getMap().get(foo2);
if (set == null) {
set = new HashSet<FooBar>();
getMap().put(foo2, set);
}
set.add(foo1);
}
And the test:
public static boolean isSame(FooBar foo1, FooBar foo2) {
if (getMap().get(foo1) == null)
return false;
return getMap().get(foo1).contains(foo2);
}
Do you really need to maintain a list of equivalences in ALL objects? If possible I would separate the set of equivalences from the objects themselves. This will be easier to maintain.
Then you can use the multimap of #posdef or more simply a Map> to stay with standard JAVA API.
Your "bidirectional" samesAs(...) method sounds like Object.equals(...), which, according to javadoc is a "an equivalence relation on non-null object references". If this is what you want, then you just have to override equals in your class.
I'm a bit lost when you say that "FooBar shouldmaintain a Set for each instances containing its equivalent instances". If you want to build equivalent classes for FooBar objects, then I think it's a good idea to use a java Collection to represent them, and more precisely a Set.
Here is a quickly hacked example:
public class FooBar {
#Override
public boolean equals(Object other) {
// do whatever fancy computation to determine if
// the object other is equal to this object
}
}
and for the equivalent class:
#SuppressWarnings("serial")
public class FooBarEquivalentClass extends HashSet<FooBar> {
#Override
public boolean add(FooBar e) {
if (isEmpty())
return super.add(e);
else if (e.equals(iterator().next()))
return super.add(e);
else
return false;
}
}
"same as" but not "equal to" sounds like you should be using Comparable.
I think it makes more sense to implement compareTo() or sameAs() as an instance method rather than a static since you will always need two real instances to do any comparison.
Sounds like what you want are to separate the equivalence groups from the object instances.
Make a Map<FooBar, Set<FooBar>> and note that when you lookup an object the set will include itself.
Sorry for the stupid question.
I'm very sure, that the Java API provides a class which wraps a reference,
and provides a getter and a setter to it.
class SomeWrapperClass<T> {
private T obj;
public T get(){ return obj; }
public void set(T obj){ this.obj=obj; }
}
Am I right? Is there something like this in the Java API?
Thank you.
Yes, I could write it y myself, but why should I mimic existing functionality?
EDIT: I wanted to use it for reference
parameters (like the ref keyword in C#), or more specific,
to be able to "write to method parameters" ;)
There is the AtomicReference class, which provides this. It exists mostly to ensure atomicity, especially with the getAndSet() and compareAndSet() methods, but I guess it does what you want.
When I started programming in Java after years of writing C++, I was concerned with the fact that I could not return multiple objects from a function.
It turned out that not only was it possible but it was also improving the design of my programs.
However, Java's implementation of CORBA uses single-element arrays to pass things by reference. This also works with basic types.
I'm not clear what this would be for, but you could use one of the subclasses of the Reference type. They set the reference in the constructor rather than setter.
It' worth pointing out that the Reference subclasses are primarily intended to facilitate garbage collection, for example when used in conjunction with WeakHashMap.
I'm tempted to ask why you'd want one of these, but I assume it's so you can return multiple objects from a function...
Whenever I've wanted to do that, I've used an array or a container object...
bool doStuff(int params, ... , SomeObject[] returnedObject)
{
returnedObject[0] = new SomeObject();
return true;
}
void main(String[] args)
{
SomeObject myObject;
SomeObject[1] myObjectRef = new SomeObject[1];
if(doStuff(..., myObjectRef))
{
myObject = myObjectRef[0];
//handle stuff
}
//could not initialize.
}
... good question, but have not come across it. I'd vote no.
.... hm, after some reflection, reflection might be what comes close to it:
http://java.sun.com/developer/technicalArticles/ALT/Reflection/
there is java.lang.ref.Reference, but it is immutable (setter is missing). The java.lang.ref documentation says:
Every reference object provides methods for getting and clearing the reference. Aside from the clearing operation reference objects are otherwise immutable, so no set operation is provided. A program may further subclass these subclasses, adding whatever fields and methods are required for its purposes, or it may use these subclasses without change.
EDIT
void refDemo(MyReference<String> changeMe) {
changeMe.set("I like changing!");
...
the caller:
String iWantToChange = "I'm like a woman";
Reference<String> ref = new MyReference<String>(iWantToChange)
refDemo(myRef);
ref.get();
I don't like it however, too much code. This kind of features must be supported at language level as in C#.
If you are trying to return multiple values from a function, I would create a Pair, Triple, &c class that acts like a tuple.
class Pair<A,B> {
A a;
B b;
public void Pair() { }
public void Pair(A a,B b) {
this.a=a;
this.b=b;
}
public void Pair( Pair<? extends A,? extends B> p) {
this.a=p.a;
this.b=p.b;
}
public void setFirst(A a) { this.a=a; }
public A getFirst() { return a; }
public void setSecond(B b) { this.b=b; }
public B getSecond() { return b; }
}
This would allow you to return 2 (techically infinite) return values
/* Reads a line from the provided input stream and returns the number of
* characters read and the line read.*/
public Pair<Integer,String> read(System.in) {
...
}
I think there is no Java API Class designed for your intent, i would also prefer your example (the Wrapper Class) then using this "array-trick" because you could insert later some guards or can check several thinks via aspects or reflection and you're able to add features which are cross-cutting-concerns functionality.
But be sure that's what you want to do! Maybe you could redesign and come to another solutions?