Removing HTML tags from Strings via SQL statements

I was just looking for a way to remove tags from strings in a database. MySQL has no support for regular expressions, so I fell back to the old way.

Just writing it down, as I think I might need it later too.

The first one is to determine which ones are to be changed. The second one changes nothing, but outputs the new result. The third one actually changed the data.

select id, adject3, adject1, adject2, adject2 from mm_items where name like '%<%' or adject1 like '%<%' or adject2 like '%<%' or adject3 like '%<%';

select adject3, concat(substring(adject3, 1, locate('<', adject3)-1), substring(adject3, locate('>', adject3) + 1)) from mm_items where adject3 like '%<%>%';

update mm_items set adject3 = concat(substring(adject3, 1, locate('<', adject3)-1), substring(adject3, locate('>', adject3) + 1)) where adject3 like '%<%>%';

Using Byteman to Find Out Why the TimeZone Changed on a Java App Server

I found the following article/blog post and I thought it worthy of mentioning it here.

Using Byteman to Find Out Why the TimeZone Changed on a Java App Server

It concerns the injection of a monitor into your application (or application server), to monitor certain method calls, and print a Stacktrace (for instance) if they occur.

Handy if it occurs deep inside a framework or production server or in one of many deployed wars, and you don't know where.

References

Developers Redhat - Using Byteman to Find Out Why the TimeZone Changed on a Java App Server

https://developers.redhat.com/blog/2018/02/21/byteman-timezone-changed/

Jboss - Byteman

http://byteman.jboss.org/

Turning a Stream into an Iterable

Recently I wanted to know how to change a stream into an Iterable. The method in the API that I need to call expects an Iterable.

I found the following solution in [1]:

public class RealEstateEvaluator
{
  public void evaluate(Session session, Iterable<House> iterable)
  {
    // do stuff
  }
}

public void realEstateEvaluation()
{
  Stream<House> housenumbersStream = 
    housenumbers.stream()
      .map(realEstateService::getHouse);   

  new RealEstateEvaluator().evaluate(getSession(), housenumbersStream::iterator);
}

However, [1] did mention that the result was unreadable. It is confusing that a method reference that provides an Iterator, perhaps accidentally, fulfills the contract for Iterable².

That's right. Iterable is an interface³, which has three methods, two of which have default implementations. Which means it has one method (iterator()), which means it can be used as a Lambda expression.

I prefer:

public void evaluate()
{
  List<House> houses = 
    housenumbers.stream()
      .map(realEstateService::getHouse)
      .collect(Collectors.toList();   

  new RealEstateEvaluator().evaluate(getSession(), houses);
}

It is a lot more readable. And I am a big believer in the Principle of Least Surprise.

All Collections are Iterables, by the way.

Update 2018-02-23: after reading and evaluating the comment below, I still think using the method reference makes it harder to read, but is much safer to use. Perhaps getting used to using stream::iterator is just a question of time.

References

[1] LambdaFAQ - How do I turn a stream into an iterable

http://www.lambdafaq.org/how-do-i-turn-a-stream-into-an-iterable/

[2] StackOverflow - Why does stream not implement iterable

https://stackoverflow.com/questions/20129762/why-does-streamt-not-implement-iterablet

[3] Oracle JavaDoc - Iterable

https://docs.oracle.com/javase/8/docs/api/java/lang/Iterable.html?is-external=true

Useless private constructors

public class NullArgumentException extends ApplicationException {

  private NullArgumentException(String message) 
  {
    super(message);
  }

  private NullArgumentException(String message, Throwable cause) 
  {
    super(message, cause);
  }

  public NullArgumentException(String field) 
  {
    super(String.format("No value for field %s", field));
  }

}

I found the code written above in our code base somewhere. My IntellIJ immediately started complaining about it.

I read through it, and then I started complaining about it too.

It looks like someone thought Constructors in Java are inherited, and wished to prevent people from instantiating the class using those constructors.

I removed the offending constructors and made the code a little cleaner.