jmail | lightweight library for working with email addresses | Email library

by RohanNagar Java Version: 1.6.2 License: MIT

X-Ray Key Features Code Snippets(3)Community Discussions(1)Vulnerabilities Install Support

kandi X-RAY | jmail Summary

jmail is a Java library typically used in Messaging, Email applications. jmail has no bugs, it has no vulnerabilities, it has build file available, it has a Permissive License and it has low support. You can download it from GitHub, Maven.

A modern, fast, zero-dependency library for working with email addresses and performing email address validation in Java. Built for Java 8 and up. Why JMail? • Installation • Usage • IP Validation • Contributing.

Support

Quality

Security

License

Reuse

Support

jmail has a low active ecosystem.

It has 74 star(s) with 3 fork(s). There are 3 watchers for this library.

It had no major release in the last 12 months.

There are 1 open issues and 18 have been closed. On average issues are closed in 31 days. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of jmail is 1.6.2

Quality

jmail has 0 bugs and 0 code smells.

Security

jmail has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

jmail code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

jmail is licensed under the MIT License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

jmail releases are available to install and integrate.

Deployable package is available in Maven.

Build file is available. You can build the component from source.

Installation instructions, examples and code snippets are available.

It has 4433 lines of code, 141 functions and 21 files.

It has medium code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi has reviewed jmail and discovered the below as its top functions. This is intended to give you an instant insight into jmail implemented functionality, and help decide if they suit your requirements.

Parses a dot domain from a string
Returns true if the domain is valid
Returns whether the given email should be allowed for any domain
The list of domain parts
Enforces that the given IP is a valid IP
Validates an IP
Returns true if the specified email is a top level domain
Compares two top - level domains
Determines whether the given email contains quoted identifiers
Returns true if the field has a Identifier
Determines whether the given email contains obsolete whitespace characters
Returns true if the text contains whitespace
Returns true if the given email contains predicates
Compares this object to another instance
Checks if the provided email is valid
Enforces that the specified email is valid
Returns a string representation of this email validator
Excludes domains that are allowed to be revoked
Verifies if the given string is a valid email
Requires only top level domains
Returns true if the given string is a valid email
Checks if an email is invalid
Determines whether the given email should be displayed for explicit source routing
Determines whether an email is allowed to be IP domain
This method generates a hashCode of this instance
Returns a new email validator

Get all kandi verified functions for this library.

jmail Key Features

No Key Features are available at this moment for jmail.

jmail Examples and Code Snippets

JMail,Usage,Bonus: IP Address Validation

Java

Lines of Code : 40

License : Permissive (MIT)

Copy

String ipv4 = "12.34.56.78";

if (InternetProtocolAddress.isValid(ipv4)) {
  // Use address
}

String ipv6 = "2001:db8::1234:5678";

if (InternetProtocolAddress.isValid(ipv6)) {
  // Use address
}

String ipv4 = "12.34.56.78";

try {
  InternetProtoc

JMail,Usage,The

Java

Lines of Code : 17

License : Permissive (MIT)

Copy

Optional parsed = JMail.tryParse("test@example.com");

Optional parsed = JMail.validator()
    .disallowIpDomain()
    .tryParse("test@example.com");

String email = JMail.tryParse("invalidEmailString")
    .map(Email::toString)
    .orElse("default@

JMail,Usage,Standard Email Validation

Java

Lines of Code : 14

License : Permissive (MIT)

Copy

String email = "test@example.com";

if (JMail.isValid(email)) {
  // Work with your email string
}

String email = "test@example.com";

try {
  JMail.enforceValid(email);
  
  // Work with your email string
} catch (InvalidEmailException) {
  // Hand

Community Discussions

Trending Discussions on jmail

Spring aspects woven by AspectJ compiler working in Maven, but not in IntelliJ IDEA

QUESTION

Spring aspects woven by AspectJ compiler working in Maven, but not in IntelliJ IDEA

Asked 2021-Dec-27 at 01:03

I'm using Spring boot 2.5.5 with AspectJ 1.9.7 (CTW). I've spotted that sometimes transactions don't roll back and to fix that I need only recompile code and run it again. For example:

I have method addB() persisting entity B, method addC() throwing exception and method A() combining them. When I call A(), exception is thrown, but entity B stays in database (as expected). When I annotate method A() with @Transactional result is the same. But if I build everything again (without any changes) then transaction is being rollbacked and there is no new record in database.

Here is my full POM:

...

ANSWER

Answered 2021-Dec-27 at 01:01

I cannot reproduce the problem because IDEA does not find the Lombok setters. Even when delegating build actions before run to Maven, I get NoSuchMethodError: '...TestEntity.setCode(java.lang.String)'. Next, I am going to try without Lombok. Please note that Lombok and AspectJ do not play nice with each other, see my answer here. Alternatively, you could also make sure that Maven does either of these:

First build with Javac + Lombok, then apply AspectJ binary weaving in a second step, all in one module.
Similar to above, but do the first build step in module A and the second one in a separate module B. Then you have an unwoven and a woven artifact, which you can both use according to your preferences. For example, you could also use the unwoven one and apply transaction aspects via load-time weaving (LTW) while starting the application. See my other answer here for both approaches #1 and #2.
Delombok the source code build the generated sources with the AspectJ compiler in a second build step.

I generated constructors, getters and setters in the IDE instead of using Lombok. Now the project compiles in both IDE and Maven. It behaves exactly as it should. With @Transactional, 0 entities are created, without it 2.

I am not sure if Lombok vs. AspectJ really is the problem due to non-compileability when using Lombok annotations, but it should be easy enough to try without Lombok for you. If it works in your context, too, we found the culprit and can think about implementing one of the 3 approaches mentioned above. Then you can tell me if you have any difficulty in doing so.

Update: I created the two-module version - Javac + Lombok, then Aspect weaving - for you in my fork and also issued pull request #1. I also improved testability a bit. See if that works for you.

Caveat: You cannot simply run DemoApplication from the application-lombok module, because that module is still unwoven and will not show transactional behaviour. But you can simply change the classpath for the run config to the application-aspectj module:

Update: As we found out in the comment section of the other answer, in addition to the problematic Lombok vs. AspectJ compiler configuration, the OP also simply had a problem with his IDE: Using IntelliJ IDEA Community Edition, he was first unaware of, then unable to install the AspectJ plugin, which means that IDEA does not know antyhing about the AspectJ compiler and simply overwrites anything which might have been compiled by AspectJ Maven before with plain Java classes. Therefore, transactional aspects do not work either, unless

either pre-run compilation is disabled and mvn compile started as an additional pre-build step for the corresponding run configuration,
or all build actions for the project are being delegated to Maven via configuration,
the OP buys a licence of IDEA Ultimate and installs the AspectJ plugin.

Source https://stackoverflow.com/questions/70436706

Community Discussions, Code Snippets contain sources that include Stack Exchange Network