Help coderanch get a
new server
by contributing to the fundraiser

Stephan van Hulst

Saloon Keeper
+ Follow
since Sep 20, 2010
Merit badge: grant badges
For More
Cologne, Germany
Cows and Likes
Cows
Total received
367
In last 30 days
1
Total given
262
Likes
Total received
4037
Received in last 30 days
15
Total given
742
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stephan van Hulst

Welcome to CodeRanch!

I'm not very familiar with Android development, but it sounds to me like you could use a GridLayout, and then inside of it you put a panel or other kind of container, to which you apply a different layout that causes your icon and text to appear next to each other.
8 hours ago
I don't really like that a web application framework takes control of my POM. I generally eschew importing third party POMs or using them as my parent POM.

I just use Spring Boot's plugins and dependencies, and all the other settings I configure myself. That means that I would be using maven.compiler.release instead of java.version as well.
23 hours ago
Java expects you to put all your dependencies on the class path. The only JAR you have on your classpath is your exbook JAR.

There are 4 ways you can solve this problem:

  • Add JSoup to the class path when you call the java command.
  • Add JSoup to your JAR's Class-Path manifest entry.
  • Use exec-maven-plugin to run your application.
  • Create a "fat JAR" that includes both JSoup and your own classes.

  • Using exec-maven-plugin would be my personal preference, but your POM already contains a start for creating a fat JAR. All you need to do is finish configuring maven-assembly-plugin and then add it to the list of plugins to execute when you're building your application.
    4 days ago

    Campbell Ritchie wrote:You have to write your own constructor and getter methods if you want to include a mutable type as a field of a record, too.


    It depends on whether immutable wrapper types exist, such as when using a Collection as a record field:

    So yes, you'd have to override the canonical constructor, but you don't necessarily need to supply custom getters.

    I posit that if you need to return mutable types from your getters (other than collection types), your design is off in the first place, and the point of supplying custom getters is moot anyway.
    1 week ago

    Campbell Ritchie wrote:Somebody's on their way to help already, the cheque's in the post, and overriding equals() is easy.


    Overriding equals() is not without its pitfalls, and its not helpful that the internet is rife with outdated and confusing examples. Even experts like Josh Bloch have given out (good) examples that (nevertheless) focus on inconsequential little warts such as the obj == this optimization, which really shouldn't be a priority when teaching how to write a good implementation.

    If you are aware of the pitfalls, overriding equals() and hashCode() really IS a tiny effort, and even if you aren't, it's not a good excuse for writing a method that performs a linear search through a hash table.
    1 week ago
    I always found the obj == this comparison a pointless optimization. Why make your code more verbose for a miniscule performance boost that doesn't matter in 98% of cases?

    The reflexivity clause is fulfilled quite neatly by comparing each field to its counterpart in the other reference.

    Campbell Ritchie wrote:Please explain more; that situation is exactly the sort of thing records are good for.


    Yes, records are perfect for simple data containers or key types. The type discussed in this topic is a good example.

    What I really dislike about record in Java is that for some reason the canonical constructor is forced to be at least as visible as the type itself, which means I can't use record in situations where I want to prevent the client from calling the constructor directly (such as when I have provided a factory method). This severely hampers an otherwise very welcome feature.
    1 week ago
    If you're on a sufficiently new compiler version, make sure to use release instead of source and target.

    This will ensure that your code is built against the intended standard API version, and not just with the intended compiler version.
    1 week ago
    Welcome to CodeRanch Eric.

    Eric Osman wrote:What is your reaction to this solution compared to one where hashCode and equals are overridden?


    I don't like it. Overriding equals() and hashCode() is a really tiny effort, and it makes your class consistent in its use for all clients, even if they don't care about hash sets.
    1 week ago
    Carey, when overriding equals() you should use instanceof and also make the method final.

    This ensures that the method works as expected across all subclasses.

    Here is my preferred solution:

    Or if you don't mind the downsides of using a record:
    1 week ago
    Strongly agree with Tim.

    A Maven project should be built exactly the same way, and yield the same results, on every system it's built, regardless of the tools you have installed on that system.

    That means that using default settings that depend on the system that the project is built on, is generally a bad idea.
    1 week ago
    Setting just maven.compiler.release is less verbose and more secure than setting both maven.compiler.source and maven.compiler.target.
    1 week ago
    Welcome to CodeRanch!

    This has nothing to do with lambda's specifically, but rather Java's rules regarding variable scopes in general.

    You are not allowed to declare a local variable when another local variable with the same name is currently in scope.

    In your first code snippet, the variable c is in scope for the duration of the lambda body, and then goes out of scope again after line 6. At line 7, there is no local variable with the name c in scope, so the declaration of the variable c is legal.

    In your second code snippet, the variable c is already in scope at line 3, and then remains for the remainder of the method body. That means you can't declare a second variable c at line 4: there is already a variable named c in scope.

    Here is an even simpler example that demonstrates the issue, without the use of lambda expressions:

    2 weeks ago
    Another good reason might be that Optional doesn't contain a method orElseThrow(Throwable).
    2 weeks ago
    Simply put, why create an object until you're definitely going to need it?
    2 weeks ago
    Sonar is a tool that supports the developer. It's not your job to make Sonar happy, it's Sonar's job to make you happy.
    2 weeks ago