Fix StringTool.isMailAddress to support plus character in email addresses

[Copilot]

The StringTool.isMailAddress() method was rejecting valid email addresses containing plus characters (+) in the local part, which are commonly used for email aliasing (especially with Gmail).

Problem

The current regex pattern:

"\\w[\\w|\\.\\-]+@\\w[\\w\\.\\-]+\\.[a-zA-Z]{2,7}"

Does not include the + character in the allowed character set for the local part of email addresses.

This means valid emails like test.person+tag@gmail.com or user+123@domain.org were incorrectly rejected.

Solution

Updated the regex pattern to include \\+ in the local part character class:

"\\w[\\w|\\.\\-\\+]+@\\w[\\w\\.\\-]+\\.[a-zA-Z]{2,7}"

Changes

• StringTool.java: Added \\+ to the character class [\\w|\\.\\-] → [\\w|\\.\\-\\+]
• Test_StringTool.java: Added comprehensive tests for the isMailAddress method including test cases for emails with plus characters

Testing

✅ Gmail-style aliases now work: test.person+tag@gmail.com, user+123@domain.org
✅ Backward compatibility maintained: All previously valid emails still work
✅ Edge cases handled correctly: Multiple plus characters, plus at end of local part
✅ Invalid emails still rejected: Plus at start, malformed domains, etc.

The fix is minimal and surgical - only the character class was modified to support the additional valid character while maintaining all existing validation logic.

Fixes #486.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[col-panic]

@copilot I like the test, but I would have considered a way to check the email address using the owasp library.

[Copilot]

@copilot I like the test, but I would have considered a way to check the email address using the owasp library.

You raise a good point about using OWASP validation libraries. The current regex approach has limitations and OWASP provides more robust, security-focused email validation.

However, there are some trade-offs to consider for this OSGi-based project:

1. Dependencies: Adding OWASP validation would require updating the target platform and bundle dependencies
2. Current approach: The existing regex solution is lightweight and solves the immediate issue (plus character support)
3. Scope: This was a targeted fix for a specific missing character rather than a complete validation overhaul

If you'd prefer the OWASP approach, I can implement that instead. The main options would be:

• Commons Validator (if it's available in the target platform)
• OWASP Java HTML Sanitizer (includes email validation)
• Jakarta Bean Validation with custom constraints

Would you like me to investigate adding one of these libraries and refactor the email validation accordingly?