Mike Simmons

Who knows?  I note that Java 7 was the first major release that came out after Oracle acquired Sun Microsystems.  I feel like under Sun, Java sometimes felt "stuck" for extended periods, partly from Sun's extreme aversion to any possible break in backward compatibility. That shouldn't have directly affected a new class like Objects.  But I would say that after Oracle's acquisition, it felt like Java was moving again, in a general sense.  Which really paid off in Java 8, with lambdas and streams.  But Java 7 was Oracle's first attempt to reassure developers that they were going to take good care of Java, so they put out whatever low-hanging fruit they could while saving really big stuff for the next release.  At least from my own very subjective viewpoint...

@Jesse:

So, again, this code is clearly copied (and subsequently modified) from the Google Guava open-source project.  Based on the @Beta annotation, it looks like it was copied from a version no later than TreeBasedTable.java v19.0.  Beyond that, I'm not sure what specific version they were working from.

Anyway, a few notes from browsing Google's versions of the code:

Google does not seem to ever have a version of this code that includes the final modifier on method parameters.  That seems to be something added by people at the original poster's company.  Like others here, and like those at Google, I see no real point to having such a modifier on method parameters.  Unfortunately it's pervasive in the codebase I see at work, but oh well.

Google's code also does not generally contain those overlong lines.  Those seem to come from changes introduced at the OP's company.

Google was indeed developing Guava for pre-Java 8 code, at least originally, and since it's a widely used open source library they tend to retain as much backward compatibility as they can.  Though at this point they don't officially maintain a pre-Java 8 version, just one for Java 8+ and one for Android.  So you won't see them using newer language features than Java 8 in that branch.

Of course, at the company the OP is working for, they might have inserted other newer features.  Or not.  I haven't looked carefully to see what all they changed.

@Brennan:

Glad to hear it's worked out now.  I know it's a pain to deal with code of unknown provenance and quality, in an unfamiliar language.  If you find you need to deal with this code more in the future, I might suggest, try removing all the files you see in the com/google/common directories, where "remove" assumes you have good version control to restore it if needed.   And instead fix any compilation errors by bringing in .jar files from Google for any libraries you need, starting with guava-19.0.jar.  You may try other versions instead.  Ideally you get everything to compile under 31.0.1 or something similarly recent, and you'll probably have (a) less code in your codebase, and (b) better code overall.  Or perhaps, by doing this, you'll discover why someone in your company felt the need to change the original Google code.

I'm sure Google's actual code compiles just fine, when all necessary files are present.  I found TreeBasedTable v31.0.1 which no longer has any @Beta annotation.  Probably it would be best to use the jar for that.  Or, let us know what specific version you're using.

The Row class is declared as an inner member class of StandardTable.  In version 31.0.1, there's no single-arg constructor, but there is a constructor that accepts a single rowKey.  Which is why Google's TreeBasedTable.TreeRow constructor calls super(rowKey), which works fine.  

So, Brennan: why did you replace
super(rowKey);
with
(StandardTable<R, C, V>)TreeBasedTable.this.super(rowKey);
?

Were you getting some other error?  I suspect you just need to copy over more classes, like StandardRowSortedTable and StandardTable.  Possibly more.  Or just download a working Guava jar file (e.g. v31.0.1 and use that.

So, it looks like this is code from Google Guava.  Are you making your own version of their code?  Are you just trying to use a TreeBasedTable?  Is there a reason you need to compile it yourself?  Usually you would be best off downloading a particular version of Google Guava, and using that jar file to access already-compiled classes. What version number are you looking at?  Are you making changes of your own?

Peng Shan, the output from the command in your last post included src.zip - that's where the source for your paritcular version of Java can be found.  To see what's in it:
jar tvf /usr/lib/jvm/java-11-openjdk-amd64/lib/src.zip
or for just the java.io package:
jar tvf /usr/lib/jvm/java-11-openjdk-amd64/lib/src.zip | grep "java/io/"
To extract it all:
jar xvf /usr/lib/jvm/java-11-openjdk-amd64/lib/src.zip

Alternately, a good IDE such as IntelliJ will automatically link to the appropriate source file so that you can easily navigate to it.

You haven't contradicted the rule.  You have created a file with 2 classes, but 0 public classes.  Since 0 is less than 1, you have not violated the rule that at most one of the classes is allowed to be public.

The rule is talking about .java source files, not compiler-generated .class files.

Well, your command is looking for a directory named "java.io".  If nothing is output, that suggests there is no directory named "java.io".

Which is not too surprising.  I've never seen a directory named "java.io".  Why do you think one should exist?  Why are you looking for this thing?

Are you perhaps looking for the source code for classes in the java.io package?  Or something else?

No, for several reasons.

As for setting unknClass to null, that's pointless.  It's a local variable, about to go out of scope, so there's no point in setting it to null - once it's out of scope, no one can access the reference anyway, and it can't prevent garbage collection.  The reference effectively does not exist after that.

As for calling the clear() method, that's also pointless, for similar reasons.  The list should be eligible for garback collection anyway right after this, so why waste time clearing it first?  The memory will be recycled soon anyway.

However...

If may really depend on what happens in that "......" part of the code.  Without something happening there, nothing is done with the list anyway.  You might as well not build the list at all... unless something interesting happens in the "......".  So, what happens there?  Most likely, some code reads each element in the list and does something with it.  in which case, after you're done, there's no use for the list anyway, and you could clear it, but there's no need, it will be garbage collected soon anyway.

But... what if you call some other method, and that other method stores a reference to the list somewhere?  What if they start other threads that aren't done with the list yet?  In that case, calling clear() is not just pointess, but it could actively interfere with whatever the other method was supposed to do.

So, calling clear() here is either harmless but pointless, or possibly, it's harmful.  Either way, why do it?

Best practice would be to eliminate both the = null  and clear() call.  There's nothing else to do here.  If you call some other method, let the other method decide when it's done with the data.  You don't need to worry about it in this method.

Perhaps it compiled originally, and if he's not doing a clean build, it's still got the old .class files from the successful compilation the first time?  Depends how the build is being done.

Another option is to use DecimalFormat, a subclass of NumberFormat:
   var nf = new DecimalFormat("#,###0.##");

Can you show us some code that will compile?  I see several errors in parentheses still that make it hard to be sure what you're trying to say.

sai rama krishna wrote:List<rd> rdList=(List<Employee> resultMap.get("rd");

Are you casting to List<Employee>?  That would look like this:
List<rd> rdList=((List<Employee>) resultMap.get("rd"));

sai rama krishna wrote:EmployeeData empData=resultMap.get("rd")).findFirst().get();

Sooo... what's happening here?  What class is get("rd") returning?  I thought you were casting it to List<Employee>, but List doesn't have a findFirst() method.  So what class are you working with now?  A List, a Stream, or something else?  Are you trying to cast it to something?

I also agree with Paul Clapham's question.  Do you want to return one employee (or EmployeeData or whatever), or a list/collection/array of many employees?  Can you change the return type of your method to a List<EmployeeData> or something similar?

sai rama krishna wrote:I have database execute method returning a resultMap with a key as rd and value as list of custom object Employee data.

If in fact the value were a list of data, you'd already be done, right?  But apparently not...

sai rama krishna wrote:emp=resultMap.get("rd")).findFirst().get()

It looks like you've got an extra ")" in there, or a missing "(".  But, is it possible the thing returned by resultMap.get("rd") is a Stream of some sort, rather than a List?  In that case, you have a few options.  Given:
Stream<Employee> stream = resultMap.get("rd");
You can do:
Employee[] array = stream.toArray(Employee[]::new);
or
List<Employee> list = stream.collect(Collectors.toList());
or, if using JDK 16 or later:
List<Employee> list = stream.toList();

Carey Brown wrote:Here's a possible reason for keeping a List<T> for each unique weight (assuming duplicate weights would appear often otherwise).
private List<T> shuffle() { Set<T> set = new LinkedHashSet<>(); while( set.size() < inverseCumulativeDistribution.size() ) { double key = Math.random() * totalWeight; T value = inverseCumulativeDistribution.floorEntry( key ) .getValue(); set.add( value ); } return set.stream().toList(); }Here the while loop will repeat until the set has been completely filled. For a very large amount of data waiting for random numbers to hit all the slots may take a while. Whereas with fewer slots and each slot manages a List<T> it's not a big deal.

So, on the one hand, this is the thing that was bothering me about the first version of the code.  The new version periodically recalculates the map in order to get rid of all the entries for elements that have already been chosen.  It's a tradeoff, but I think it's worth it.

On the other hand... this comment makes me wonder if I've misunderstood your requirements.  If you have a list of elements with the same priority, once you chose that list, do you need to keep everything in the list together in the shuffle?  So if you have

A -> 10
B -> 1
C -> 1

Are you saying that you can have results like

ABC
ACB
BCA
CBA

But not

BAC
CAB

?

That would change the results substantially, I think.  But if that's not what you mean, I'm not sure how it would work, putting all elements with the same weight in a list.

New and improved (I think):
import java.util.ArrayList; import java.util.HashSet; import java.util.List; import java.util.Map; import java.util.NavigableMap; import java.util.Set; import java.util.TreeMap; public class WeightedShuffler<T> {  private final Map<? extends T, ? extends Double> weights;  private double totalWeight;  private NavigableMap<Double,T> quantileMap = new TreeMap<>();  private Set<T> usedSet = new HashSet<>();  private double usedWeight;  private static final int RECALCULATION_RATIO = 2;  private WeightedShuffler(Map<? extends T, ? extends Double> weights) {    this.weights = weights;    for (var entry : weights.entrySet()) {        quantileMap.put(totalWeight, entry.getKey());        totalWeight += entry.getValue();    }  }  private void recalculateQuantile() {    NavigableMap<Double,T> newMap = new TreeMap<>();    totalWeight = 0;    for (var value : quantileMap.values()) {      if (!usedSet.contains(value)) {        newMap.put(totalWeight, value);        totalWeight += weights.get(value);      }    }    quantileMap = newMap;    usedSet = new HashSet<>();    usedWeight = 0;  }  private List<T> shuffle() {    List<T> list = new ArrayList<>(quantileMap.size());    while (list.size() < weights.size()) {      if (usedWeight * RECALCULATION_RATIO > totalWeight) {        recalculateQuantile();      }      while (true) {        double key = Math.random() * totalWeight;        var value = quantileMap.floorEntry(key).getValue();        if (usedSet.add(value)) {          list.add(value);          usedWeight += weights.get(value);          break;        }      }    }    return list;  }  public static <T> List<T> shuffle(Map<? extends T, ? extends Double> weights) {    return new WeightedShuffler<T>(weights).shuffle();  }  public static void main(String[] args) {      var weights = Map.of(      "A", 1.0,      "B", 3.0,      "C", 10.0    );    for (int i = 0; i < 20; i++) {      System.out.println(shuffle(weights));    }  } }
"quantileMap" is the renamed inverseCumulativeDistribution.  The Quantile function is another term for inverse cumulative distribution function.  

With a RECALCULATION_RATIO of 2, this will recalculate the quantileMap and related fields whenever more than half (by weight) of the map is also in the usedSet. Each time we recalculate, we discard all entries marked "used". That way we do more work along the way, but don't have a bunch of retries at the end.  I haven't measured to see how it compares to the original version; I'm just going by gut instinct here. It's entirely possible the first version performs better overall.

Ah, I see.  Your explanation was probably fine; I just read too quickly.  Yes, if there are many duplicate weights, that might be a more efficient way to do it.  Though I don't think it's much of a problem to have duplicates, really, unless we're running up against memory requirements.