Rob Spoor

Path src/main/resources/static/media will not work. While this is indeed the location where you put the files, it's not where Spring Boot serves them from. Files are instead served from the class path, starting with /static. The contents of src/main/resources/static/media are made part of the class path when the application is built, but afterwards that's no longer true. When you run the application from your IDE, the actual path is instead target/classes/static/media. When you build your Spring Boot application and run the resulting JAR file, you can't even change contents on the class path.

A better idea is to take an external path (configured in application.yml / application.properties) where you store files (or hard code it), and add that to your Spring Boot application's resource path. To do this, create a class that implements WebMvcConfigurer (or modify your possibly existing one), override addResourceHandlers and add a resource handler to your ResourceHandlerRegistry. For an example, see section 3 of https://www.baeldung.com/spring-mvc-static-resources.

Your regex only match anchor elements, not image elements. You should either use more regexes (ugh), or make your current regex more flexible (ugh).

There is a sneaky workaround that abuses the code used by Swing to render HTML in editor panes. Class HTMLEditorKit.Parser can be used to perform (basic) HTML parsing for you (although it's limited to HTML 3.2...).

To use this, create an instance of ParserDelegator, implement a ParserCallback, and call the parse method. The trick is in writing the ParserCallback - the handleSimpleTag and handleStartTag​ give you access to the elements and their attributes. You should at least check for attributes HTML.Attribute.HREF and HTML.Attribute.SRC.


(If you want to have better HTML parsing support, you can use DocumentParser instead, if you can create a correct DTD instance.)

I agree. While it's both possible and allowed, it should not be desired.

I was thinking of doing what OpenJDK has (from file test/jdk/java/util/Optional/Basic.java):
checkEmpty(Optional.<String>empty().filter(s -> { fail(); return true; }));
Applied to Jeanne's code it would become this:
MyObject match = list.stream().    .filter(x -> x.getKey() == 1)    .findAny()    .orElseGet(() -> { fail("Key 1 not found"); return null; });
But I like Devaka's example better, it's much clearer.

If you're going for readability, then yes, that is a good order. But when you look at performance, especially memory footprint, then the old loop is better for ArrayLists, and streams are probably the worst (unfounded, but I'm just guessing that it involves more objects than just an Iterator).

For Strings with toCharArray performance is actually going to be terrible for large Strings, because it first needs to create the char[]. Here are the Java 8 and 12 versions:
   public char[] toCharArray() {        // Cannot use Arrays.copyOf because of class initialization order issues        char result[] = new char[value.length];        System.arraycopy(value, 0, result, 0, value.length);        return result;    }    public char[] toCharArray() {        return isLatin1() ? StringLatin1.toChars(value)                          : StringUTF16.toChars(value);    }
I'm not going into the StringLatin1 or StringUTF16 code, but essentially, in both versions the entire contents of the String is copied, and that takes both memory and CPU cycles. You actually loop over the String twice - once for creating the char[] and then once over the char[].


Summarising: streams and for-each loops are great unless you really have to look at memory, and String.toCharArray() is the worst way to loop over a String.

I hate toCharArray. It creates a fresh new char[] every time it's invoked. I prefer to loop over the String using the CharSequence interface methods:
for (int i = 0; i < sentence.length(); i++) {    char ch = sentence.charAt(i); }
I don't use streams for looping that much yet, I still get a feeling that unless you're parallelizing a simple for-loop will be more efficient - if not in speed, at least in memory.

How do you deploy your application? Because I've downloaded your MSSQL server driver from mvnrepository.com and it contains the class that is reported as missing.

You should be good there. Table.indexes has been added in JPA 2.1. You're using both JPA 2.2 and Hibernate 5.4.2. While that could be asking for trouble if there is a compatibility mismatch, https://hibernate.org/orm/releases/ shows that Hibernate 5.4 should be JPA 2.2 compatible.

If you remove the JPA dependency and only use the Hibernate one, can you then still compile your code with Table.indexes?

There are three very clear errors in your code:

1) You always set the position argument to 10, so no matter what Fibonacci number you want, you would always get the same value (for position 10).
2) Your loop body always does the exact same thing. It doesn't use the loop counter, but always does the same thing, regardless of the input.
3) You always return 0.

You need to step away from a computer, and write down on paper how you would do this first.

Welcome to the Ranch!

It seems there is no replacement, and that makes sense to be honest. I found https://docs.spring.io/spring/docs/3.2.4.RELEASE_to_4.0.0.M3/Spring%20Framework%203.2.4.RELEASE/org/springframework/ejb/support/AbstractStatelessSessionBean.html which mentions that the class is to support EJB 2.x beans. Those should no longer be used anywhere that is not ancient legacy code, and even in Spring 3.2 this class and all other classes / interfaces in the same package were deprecated; see https://docs.spring.io/spring/docs/3.2.4.RELEASE_to_4.0.0.M3/Spring%20Framework%203.2.4.RELEASE/org/springframework/ejb/support/package-summary.html.

You probably have to rewrite some code this time. Since you're going up two major versions, that shouldn't come as a surprise though.

Matthew Fleming wrote:

Campbell Ritchie wrote:Why does your Specimen return 1/0 for whether it has been viewed or not? What is wrong with a boolean return type?

Because Mysql last I checked doesn't have a boolean type. I might be wrong about this, but in any case it is irrelevant.

You're right, but JPA will map boolean to 0/1 internally. Unless you're using native queries, there is no need to use 0/1.

Also, wouldn't 0/1 as ints (or bytes) be more logical than chars?

You're welcome.

Maybe there is some white space at the end. You can't easily see that when it's printed out without something visually following it. Print something after the values:
System.out.println(rs.getString("isbn13") + ";");

That's a horrible example. If the finally block does not cause an exception, the original exception is never thrown. The following would be a better version:
Exception original = null; DirtyResource resource = new DirtyResource(); try {    resource.accessResource(); } catch (Exception e) {    original = e; } finally {    try {        resource.close();    } catch (Exception e) {        if (original == null) {            throw e;        } else {            original.addSuppressed(e);            throw original;        }    }    if (original != null) {        throw original;    } }
This not only throws an exception whenever anything went wrong, it also throws the correct exception - the one thrown from the main body, not the one thrown from the cleanup.

Of course, the following is (nearly) identical to the above but much, much cleaner:
try (DirtyResource resource = new DirtyResource()) {    resource.accessResource(); }
The only thing that's different is the scope of the resource variable.