This pull request fixes #13. Rather than using a mixture of indexOf and regular expressions, we've gone wholesale with an approach that extracts substrings between specified delimiters. The resulting code is shorter and hopefully more performant (regexes being slow, but we haven't actually benchmarked things!). Note that this will only work if the RQF components are used in this exact order, as described in the RFC 8141 spec.

We've accompanied the revised implementation with two unit tests that would have failed with the original code.

Thanks to @danielthepope for pairing on this task. Thanks in advance for reading!

The GNU General Public License v3.0 imposes conditions on any software integrating a GPL license artifact which are rarely compatible with commercial software.

Switching to LGPL (GNU Lesser General Public License) would broaden the number of projects in which this library can be used.

Please note in April 2017 the URN RFC was updated. See RFC8141. Major differences, see Wikipedia:

The slash character (/) is now allowed in the NSS to represent names containing slashes from non-URN identifier systems. The q-component was added to enable passing of parameters to named resources. The r-component was added to enable passing of parameters to resolvers. However, the updated specification notes that the r-component should not be used until its semantics are defined via further standardization.

An exception is silently catched without explanation: source

My guess is the exception "cannot happen", but a brief explanation (in the form of an in-line comment) would be nice :)

Looks like maven central does not play such a central role for Java like CPAN does for Perl, npm for JavaScript or Composer for PHP but I would not like to reuse a module that is not published in such a repository.

According to the Java specification for hashCode:

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

This true for URN_2141 objects but not for URN_8141 objects. Indeed, the two following URNs are equal but produce different hashCodes:

URN.rfc8141().parse("urn:example:foo-bar-baz-qux?+CCResolve:cc=uk?=op=map#somepart"); 
URN.rfc8141().parse("urn:example:foo-bar-baz-qux");

This is due to the fact that hashCode, which calls toString in the current implementation, takes the RQF components into account, whereas equals does not.

According to RFC 8141, RQF components should not be taken into account for URN-equivalence, so I suggest changing `hashCode's implementation to reflect this. We're happy to contribute this fix! 👍

We've identified an issue where, if a URN contains both an r- and a q- component, the library fails to parse the r-component correctly.

urn:example:foo?+key=value?=fizz=buzz says the r-component is key= (value is empty string). We believe there is an issue with the regular expression that is trying to extract the r-component.

The issue also occurs when the URN contains a f-component, either with or without the q-component.

This library is good stuff. Thank you for creating it. 🥇

One minor issue: very often we need to define URNs as static constants in a class. Doing so isn't easy because there's no way to create a URN that doesn't raise an exception (even though we know the URN is a perfectly valid URN). There should be a method similar to URI#create. This method should wrap the URNSyntaxException and raise an IllegalArgumentException. That would make it possible to define URNs as a static constant:

 public static final URN EXAMPLE_URN = URN.create("urn:example:example");

The syntax description for URN NSS parts doesn't allow for NSS parts to be empty. Currently this is considered a valid URN: urn:foo:::::bar.

According to NSS part syntax NSS should have at least one character.

See ABNF for RFCs on this: https://tools.ietf.org/html/rfc5234#page-9

Bumps junit from 4.12 to 4.13.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

TravisCI seems to have stopped supporting OpenJDK 7 and OracleJDK 8. Adjust .travis.yaml file.

https://travis-ci.community/t/oraclejdk-7-not-supported-on-precise/3643

Hello,

I wonder if it's normal that de.slub.urn.RQF_RFC8141.initialToString() concat q and r component without & ?

If it's not, do you like a p.r ?

Thanks in advance.

I'm using urnlib for handling URNs according to RFC 4198. RFC 4198 describes, that RessourceIds, part of Namespacespecific part of a URN, can be in a hexadecimal format, starting with a "%" (Chapter 3 Specification Template). Since I address the content via SHA-1 hashes, this part of the specification is relevant to me. Typically, a FDC URN in my case looks like: urn:fdc:127.0.0.1:20220902:%FFFF When I save this urn in a file via urn.toString() the result looks like: urn:fdc:127.0.0.1:20220902:%ffFF. It's a source of incompatibility, if these URNs are used by other tools. I think, urnlib detects a URL Encoded string, because of the existence of %. Could you please have a look at that?

Since RFC 8141 is backward compatible to RFC 2141 and succeeds the old RFC, code supporting RFC 2141 can be removed in further major releases in order to clear up the API.