Method references basically fit to 2 rules I think:
1. When you invoke method on argument, i.e.:
so it can be replaced with:
2. When you pass singular argument to another method, either static or instance:So you can replace with:
And that is basically it. Alright, there are still those cases where you create an array let's say, but they I think they fit to one of those 2 examples.
The filter() arguments you use have kind of a backwards perspective from what I would expect.
I would expect something more like this:
While it may help keep your example code shorter, I think that putting the filtering methods in the Main class gives a poor (and potentially misleading) context for the example. The reasons to avoid using a class like Main to hold your filtering methods are similar to the reasons why we advise beginners to have their Main class as a "driver" class for their actual program class, like a Game class, for example.
A better way to present it would probably be to have a separate EmployeeSelectors or EmployeeFilters class or just use Employee methods.
A separate Selector or Filter class would be warranted if you have somewhat specialized criteria, like "is a pirate", that you'd rather not have lumped in with the primary object. Let's say you don't feel like it's appropriate to have an Employee.isPirate() method or let's say you'd like to externalize the "business rule" of who is a senior vs. junior employee. You could have the special criteria in a separate but related class or enum:
You can use the EmployeeSelectors.INSTANCE like this:
In your Employee class, you eliminate the isSenior() method and replace it with a simple getYears() method. Now you have separated the logic/rules for "employee seniority" to a secondary employee-related class (or enum in this case)
And since the motivation was to separate the rule for employee seniority from the Employee domain object, I'd probably refactor(rename) that enum from EmployeeSelector to something like EmployeeSeniorityRule or something like that.
If you compare https://repl.it/Mzt2/5 with https://repl.it/Mzt2/2, you'll notice that no change had to be made to Employee when I refactored EmployeeSeniorityRule. This is a benefit you get from separating this kind of logic.
Be careful when you do this kind of thing though because overdoing it could result in an anemic domain model, one of the more dangerous liabilities of which is breaking of encapsulation. In this case, providing a getYear() method that is primarily intended for use by things like EmployeeSeniorityRule isn't too much of a concern since the design choice is intentional and consequences are limited.