Mike Simmons

Campbell Ritchie wrote:Of course, the Stream technique you are suggesting gives a very elegant two‑line solution.

Not sure why a second line would be required.

OK, Google Collections hasn't been updated in over a decade, and it was replaced with Guava.  So, I'd just remove the google collections jar.  If that creates any compilation problems, we may have to find replacements for the old code using the newer jar.  But that shouldn't be too much trouble...

[ignore, post was unneeded since you've now already seen the problem.]

OK, that may make it easier.  Can you tell what google jar file versions you have?  If you use Eclipse to look up the Strings and Platform classes, what jar file(s) are they found in?

Typically this means that you've got incompatible versions of one or more libraries.  In this case it sounds like the jar file that contains com.google.common.base.Strings is incompatible with the jar file that contains com.google.common.base.Platform.  Which is strange since they'd normally be in the same jar file.  Most likely there are two different related jar files in your environment, and they don't play well together.  You will probably need to identify what part of of your build configuration is brining in the old version of the file, and modify it so it instead references the new version instead.  Then only one version of com.google.common.base classes will be present, and it will be self-consistent.

How are you building this project?  Are you using maven (mvn), or some other tool?  And are you using an IDE such as IntelliJ or Eclipse?  This will help us give further guidance in how to fix this.

I think there will also be problems with the import statement, and the lack of any containing class.  And, what's "pick", anyway?

OK, so, what happens when you try to compile it and run it?  Do you get any error message?

I hope the original poster was not still waiting.

Well, historically people have used ArrayList for almost everything in Java, even where an immutable list would be better.  That's simply because immutable lists weren't part of Java's libraries initially.  Now they're somewhat easier with List.of() and other techniques.  But you will still see ArrayList used in Java in many places where it's not the best fit necessarily.  So don't let that carry over to Scala.   When you need a mutable list, ListBuffer is a good candidate.  But if you don't need mutability, don't use it.

Having said that, in terms of performance characteristics, ListBuffer looks similar to ArrayList, except it also offers constant-time prepending, like LinkedList or ArrayDeque.  Probably it has similar weaknesses if you need to add or delete away from the ends.  But I haven't looked closely at its internals.

That's true, but misses the point of the question.  Yes, an immutable class needs to be final, or have some other way to prevent extension, in order to be truly immutable.  So make Immutable final.  As for EffectivelyImmutable, obviously it's not required to obey all rules for being immutable - that's the point.  Effectively immutable means it's not actually immutable, but it's being used in a way that its fields are never being changed after construction... so naively, we'd expect it to be immutable, and moreover, if we obey the rules of safe publication, it will be guaranteed to actually behave as if it were immutable.

The flip side is, if you have an effectively immutable object, and you don't obey the rule of safe publication, you may get unexpected behavior.

Here, I've taken Michael's original code and added a bit.  I made both Immutable and EffectivelyImmutable final, and given them a shared interface with a getI() method to make them easier to compare.  The only difference between the two is, Immutable has a final int field i, and EffectivelyImmutable has a non-final int field i.  Then we create some instances and put them where other threads can find them and do something with them.

import java.util.*; public class SafeAndUnsafePublication {    interface Item {        int getI();    }        static final class Immutable implements Item {        private final int i;        public Immutable(int i) { this.i = i;}        public int getI() { return i; }    }    static final class EffectivelyImmutable implements Item {        private int i;        public EffectivelyImmutable(int i) { this.i = i;}        public int getI() { return i; }    }    public static void main(String[] args) {        startQueueReader();        Item ei = new EffectivelyImmutable(42);        publishUnsafely(ei);        publishSafely(ei);        Item i = new Immutable(42);        publishUnsafely(i);        publishSafely(i);    }    private static void startQueueReader() {        new Thread(() -> {            while (true) {                process(unsafeQueue);                process(safeQueue);            }        }).start();    }    private static void process(List<Item> list) {        if (!list.isEmpty()) {            try {                Item item = list.remove(0);                if (item != null) {                    System.out.println(item.getI());                }            } catch (NoSuchElementException e) {                // ignore - not the point of this code            }        }    }    private static void publishUnsafely(Item gi) {        unsafeQueue.add(gi);    }    private static void publishSafely(Item gi) {        safeQueue.add(gi);    }    private static final List<Item> unsafeQueue = new LinkedList<>();    private static final List<Item> safeQueue = Collections.synchronizedList(new LinkedList<>()); }
Now, this code is pretty silly.  And I'm deliberately avoiding some more modern threading constructs like ExecutorService or an ArrayBlockingQueue because those take additional precautions to promote thread safety, and I'm deliberately trying to make an *unsafe* example.  And I have a hard time analyzing all the rules for this, so I'm staying away from some more complex cases that I don't feel like trying to analyze.

We have two methods of publication here.  The unsafe one adds an item to a LinkedList.  The safe one does the same thing, except the LinkedList is wrapped with Collections.synchronizedList().  That means synchronization is used to access the data in the list, which is one of the ways to guarantee safe publication.  Both lists are then polled from another thread, and getI() is called to observe the value of the field i.  Which, we would expect, would be 42.

The point of this code is, when you use unsafe publication on an effectively immutable object, you may observe that the item.getI() code will return a 0, rather than the 42 that any sane person would expect here.  Now in practice, you will almost certainly not see this.  It's pretty unlikely.  But it's possible, theoretically.  If you run the code many, many times, you may have a higher chance of actually observing it.  It may never happen, on your machine.  But there are other machines out there that may exhibit this behavior.

Conversely, if we use safe publication on an EffectivelyImmutable instance, we are guaranteed to never see 0, only 42.  And when we use an Immutable, whether published safely or unsafely, we are also guaranteed to see 42, never 0.

For most of us, using immutable instances is easier to understand.  Using effectively immutable instances and making sure they're only published safely, that's harder to get right, more things can go wrong.  But, it is one way of achieving thread safety in your programs.

Sounds like you would need to show some code of exactly what you did.

The problem comes from using a raw type here:
List numbers = Arrays.asList(3,2,2,3,7,3,5);
You haven't said what sort of List, so the compiler has to treat it as a List of some unknown thing.  Later when you want it treated as an int, the compiler doesn't want to, because it could be an Object, or a String, or a Date, etc.  You could fix this by explicitly casting:
.mapToInt((x)->(Integer) x)
But the better solution would be to use a proper generic type in the first place:
List<Integer> numbers = Arrays.asList(3,2,2,3,7,3,5);
Alternately, you could do
var numbers = Arrays.asList(3,2,2,3,7,3,5);
and Java will pick up the correct type for you.  Or:
Stream.of(3,2,2,3,7,3,5)
or even
IntStream.of(3,2,2,3,7,3,5)

It can be interesting to try each of these to see how that changes the subsequent code.

What I meant was, do you have a complete list of all possible values?  Are all values either s or t?  Do they range from a-z?  Or is there some other list, like C, M, T, S, X?

If all the values are s or t, then make all s = 0, and all t = 1.  That's easy.

If it's a range a-z, then ou can convert from the char to an int using math:
char ch = 's'; int i = ch - 'a'; System.out.println("ch=" + ch); System.out.println("((int) ch)=" + ((int) ch)); System.out.println("((int) 'a')=" + ((int) 'a')); System.out.println("i=" + i);

If it's a more random list like c, m, t, s, x or something, then go back to that labelIndices code I showed to make a more flexible way of mapping each unique label to an int.

Apparently, Sensitivity applies only to a binary classification, which means there are only two classes.In your example they are all 13 or 15, which is good.  However it looks like Smile enforces "binary" by saying the classes must be either 0 or 1.  So you could replace all 13 with 0, and all 15 with 1.   Or the other way around.  It doen't matter which you choose, as long as you remember what 0 means, and what 1 means, based on how you have converted the 13 and 15 to 0 or 1.

And when you click on Single-responsibility principle you get a page that has the following as its first paragraph:

The single-responsibility principle (SRP) is a computer-programming principle that states that every module, class or function in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility.

So it seems that the first page just has a very quick summary which omits some details.  Doesn't mean those details aren't important... it just means that the summary is not a complete statement of everything that might be important to know.