A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://docs.pmd-code.org/pmd-doc-7.0.0-rc3/pmd_release_notes_pmd7.html below:

Detailed Release Notes for PMD 7

These are the detailed release notes for PMD 7.

🚀 Major Features and Enhancements New official logo

Many of you probably have already seen the new logo, but now it’s time to actually ship it. The new logo was long ago decided (see #1663).

We decided it’s time to have a modernized logo and get rid of the gun. This allows to include the logo anywhere without offense.

The official logo is also without a tagline (such as “Code Quality Matters!”) as the tagline created some controversies. Without a tagline, we are not limited in the direction of future development of PMD.

The new logo is available from the Logo Project Page.

Revamped Java

The Java grammar has been refactored substantially in order to make it easier to maintain and more correct regarding the Java Language Specification. It supports now also the edge-cases where PMD 6 was failing (e.g. annotations were not supported everywhere). Changing the grammar entails a changed AST and therefore changed rules. The PMD built-in rules have all been upgraded and many bugs have been fixed on the way. Unfortunately, if you are using custom rules, you will most probably need to accommodate these changes yourself.

The type resolution framework has been rewritten from scratch and should now cover the entire Java spec correctly. The same is true for the symbol table. PMD 6 on the other hand has always had problems with advanced type inference, e.g. with lambdas and call chains. Since it was built on the core reflection API, it also was prone to linkage errors and classloader leaks for instance. PMD 7 does not need to load classes, and does not have these problems.

The AST exposes much more semantic information now. For instance, you can jump from a method call to the declaration of the method being called, or from a field access to the field declaration. These improvements allow interesting rules to be written that need precise knowledge of the types in the program, for instance to detect UnnecessaryBoxing or UseDiamondOperator. These are just a small preview of the new rules we will be adding in the PMD 7 release cycle.

Overall, the changes to the parser, AST, type resolution and symbol table code has made PMD for Java significantly faster. On average, we have seen ~2-3X faster analysis, but as usual, this may change depending on your workload, configuration and ruleset.

Contributors: Clément Fournier (@oowekyala), Andreas Dangel (@adangel), Juan Martín Sotuyo Dodero (@jsotuyod)

Note:

The full detailed documentation of the changes are still work in progress. Some first results of the Java AST changes are for now documented in the Wiki:

Java clean changes

. It is planned to move the contents of the wiki page into this document before the final release of PMD 7.

Annotations

Annotations are consolidated into a single node. SingleMemberAnnotation, NormalAnnotation and MarkerAnnotation are removed in favour of ASTAnnotation. The Name node is removed, replaced by a ASTClassOrInterfaceType.

Those different node types implement a syntax-only distinction, that only makes semantically equivalent annotations have different possible representations. For example, @A and @A() are semantically equivalent, yet they were parsed as MarkerAnnotation resp. NormalAnnotation. Similarly, @A("") and @A(value="") were parsed as SingleMemberAnnotation resp. NormalAnnotation. This also makes parsing much simpler. The nested ClassOrInterface type is used to share the disambiguation logic.

Related issue: [java] Use single node for annotations (#2282)

Annotation AST Examples Code Old AST (PMD 6) New AST (PMD 7) 
@A

+ Annotation
  + MarkerAnnotation
    + Name "A"

+ Annotation
  + ClassOrInterfaceType "A"

@A()

+ Annotation
  + NormalAnnotation
    + Name "A"

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList

@A(value="v")

+ Annotation
  + NormalAnnotation
    + Name "A"
    + MemberValuePairs
      + MemberValuePair "value"
        + MemberValue
          + PrimaryExpression
            + PrimaryPrefix
              + Literal '"v"'

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList
    + MemberValuePair "value" [@Shorthand=false()]
      + StringLiteral '"v"'

@A("v")

+ Annotation
  + SingleMemberAnnotation
    + Name "A"
    + MemberValue
      + PrimaryExpression
        + PrimaryPrefix
          + Literal '"v"'

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList
    + MemberValuePair "value" [@Shorthand=true()]
      + StringLiteral '"v"'

@A(value="v", on=true)

+ Annotation
  + NormalAnnotation
    + Name "A"
    + MemberValuePairs
      + MemberValuePair "value"
        + MemberValue
          + PrimaryExpression
            + PrimaryPrefix
              + Literal '"v"'
      + MemberValuePair "on"
        + MemberValue
          + PrimaryExpression
            + PrimaryPrefix
              + Literal
                + BooleanLiteral [@True=true()]

+ Annotation "A"
  + ClassOrInterfaceType "A"
  + AnnotationMemberList
    + MemberValuePair "value" [@Shorthand=false()]
      + StringLiteral '"v"'
    + MemberValuePair "on"
      + BooleanLiteral [@True=true()]
Types Declarations

TODO

Statements

TODO

Expressions

used to be parsed as

Expression
+ PrimaryExpression
  + PrimaryPrefix
    + AllocationExpression
      + ClassOrInterfaceType[@Image="Foo"]
  + PrimarySuffix
    + Arguments
  + PrimarySuffix
    + Name[@Image="bar.foo"]
  + PrimarySuffix
    + Arguments
      + ArgumentsList
        + Expression
          + PrimaryExpression
            + Literal[@ValueAsInt=1]

It’s now parsed as

MethodCall[@MethodName="foo"]
+ FieldAccess[@FieldName="bar"]
  + ConstructorCall
    + ClassOrInterfaceType[@TypeImage="Foo"]
    + ArgumentsList
+ ArgumentsList
  + NumericLiteral[@ValueAsInt=1]

Instead of being flat, the subexpressions are now nested within one another. The nesting follows the naturally recursive structure of expressions:

new Foo().bar.foo(1)
---------            ConstructorCall
-------------        FieldAccess
-------------------- MethodCall

This makes the AST more regular and easier to navigate. Each node contains the other nodes that are relevant to it (e.g. arguments) instead of them being spread out over several siblings. The API of all nodes has been enriched with high-level accessors to query the AST in a semantic way, without bothering with the placement details.

The amount of changes in the grammar that this change entails is enormous, but hopefully firing up the designer to inspect the new structure should give you the information you need quickly.

TODO write a summary of changes in the javadoc of the package, will be more accessible.

Note: this doesn’t affect binary expressions like ASTAdditiveExpression. E.g. a+b+c is not parsed as

AdditiveExpression
+ AdditiveExpression
  + (a)
  + (b)
+ (c)

It’s still

AdditiveExpression
+ (a)
+ (b)
+ (c)

which is easier to navigate, especially from XPath.

Revamped Command Line Interface

PMD now ships with a unified Command Line Interface for both Linux/Unix and Windows. Instead of having a collection of scripts for the different utilities shipped with PMD, a single script pmd (pmd.bat for Windows) can now launch all utilities using subcommands, e.g. pmd check, pmd designer. All commands and options are thoroughly documented in the help, with full color support where available. Moreover, efforts were made to provide consistency in the usage of all PMD utilities.

$ Usage: pmd [-hV] [COMMAND]
  -h, --help      Show this help message and exit.
  -V, --version   Print version information and exit.
Commands:
  check     The PMD standard source code analyzer
  cpd       Copy/Paste Detector - find duplicate code
  designer  The PMD visual rule designer
  cpd-gui   GUI for the Copy/Paste Detector
              Warning: May not support the full CPD feature set
  ast-dump  Experimental: dumps the AST of parsing source code
Exit Codes:
  0   Successful analysis, no violations found
  1   An unexpected error occurred during execution
  2   Usage error, please refer to the command help
  4   Successful analysis, at least 1 violation found

For instance, where you previously would have run

run.sh pmd -d src -R ruleset.xml

you should now use

pmd check -d src -R ruleset.xml

or even better, omit using -d / --dir and simply pass the sources at the end of the parameter list

pmd check -R ruleset.xml src

Multiple source directories can be passed, such as:

pmd check -R ruleset.xml src/main/java src/test/java

And the exact same applies to CPD:

pmd cpd --minimum-tokens 100 src/main/java

Additionally, the CLI for the check command has been enhanced with a progress bar, which interactively displays the current progress of the analysis.

This can be disabled with the --no-progress flag.

Finally, we now provide a completion script for Bash/Zsh to further help daily usage. This script can be found under shell/pmd-completion.sh in the binary distribution. To use it, edit your ~/.bashrc / ~/.zshrc file and add the following line:

source *path_to_pmd*/shell/pmd-completion.sh

Contributors: Juan Martín Sotuyo Dodero (@jsotuyod)

Full Antlr support

PMD 6 only supported JavaCC based grammars, but with Antlr parsers can be generated as well. Languages backed by an Antlr grammar are now fully supported. This means, it’s now possible not only to use Antlr grammars for CPD, but we can actually build full-fledged PMD rules for them as well. Both the traditional Java visitor rules, and the simpler XPath rules are available to users. This allows to leverage existing grammars.

We expect this to enable both our dev team and external contributors to largely extend PMD usage for more languages.

Two languages (Swift and Kotlin) already use this new possibility.

Contributors: Lucas Soncini (@lsoncini), Matías Fraga (@matifraga), Tomás De Lucca (@tomidelucca)

Updated PMD Designer

This PMD release ships a new version of the pmd-designer. For the changes, see PMD Designer Changelog.

New CPD report format cpdhtml-v2.xslt

Thanks to @mohan-chinnappan-n a new CPD report format has been added which features a data table. It uses an XSLT stylesheet to convert CPD’s XML format into HTML.

See the example report.

New: Swift support

Given the full Antlr support, PMD now fully supports Swift. We are pleased to announce we are shipping a number of rules starting with PMD 7.

Contributors: Lucas Soncini (@lsoncini), Matías Fraga (@matifraga), Tomás De Lucca (@tomidelucca)

New: Kotlin support (experimental)

PMD now supports Kotlin as an additional language for analyzing source code. It is based on the official kotlin Antlr grammar. Java-based rules and XPath-based rules are supported.

Kotlin support has experimental stability level, meaning no compatibility should be expected between even incremental releases. Any functionality can be added, removed or changed without warning.

We are shipping the following rules:

Contributors: Jeroen Borgers (@jborgers), Peter Paul Bakker (@stokpop)

New: CPD support for TypeScript

Thanks to a contribution, CPD now supports the TypeScript language. It is shipped with the rest of the JavaScript support in the module pmd-javascript.

Contributors: Paul Guyot (@pguyot)

New: CPD support for Julia

Thanks to a contribution, CPD now supports the Julia language. It is shipped in the new module pmd-julia.

Contributors: Wener (@wener-tiobe)

New: CPD support for Coco

Thanks to a contribution, CPD now supports Coco, a modern programming language designed specifically for building event-driven software. It is shipped in the new module pmd-coco.

Contributors: Wener (@wener-tiobe)

Changed: JavaScript support

The JS specific parser options have been removed. The parser now always retains comments and uses version ES6. The language module registers a couple of different versions. The latest version, which supports ES6 and also some new constructs (see Rhino]), is the default. This should be fine for most use cases.

Changed: Language versions

We revisited the versions that were defined by each language module. Now many more versions are defined for each language. In general, you can expect that PMD can parse all these different versions. There might be situations where this fails and this can be considered a bug. Usually the latest version is selected as the default language version.

The language versions can be used to mark rules to be useful only for a specific language version via the minimumLanguageVersion and maximumLanguageVersion attributes. While this feature is currently only used by the Java module, listing all possible versions enables other languages as well to use this feature.

Related issue: [core] Explicitly name all language versions (#4120)

Changed: CPP can now ignore identifiers in sequences (CPD) 🌟 New and changed rules New Rules

Apex

Java

Kotlin

Swift

Changed Rules

General changes

Apex General changes

Java General changes

Java Best Practices

Java Codestyle

Java Design

Java Documentation

Java Error Prone

Deprecated Rules

In PMD 7.0.0, there are now deprecated rules.

Removed Rules

The following previously deprecated rules have been finally removed:

Apex

Java

💥 Compatibility and Migration Notes For endusers For integrators 🚨 API

The API of PMD has been growing over the years and needed some cleanup. The goal is, to have a clear separation between a well-defined API and the implementation, which is internal. This should help us in future development.

This however entails some incompatibilities and deprecations, see also the sections New API support guidelines and API removals below.

New API support guidelines

Until now, all released public members and types were implicitly considered part of PMD’s public API, including inheritance-specific members (protected members, abstract methods). We have maintained those APIs with the goal to preserve full binary compatibility between minor releases, only breaking those APIs infrequently, for major releases.

In order to allow PMD to move forward at a faster pace, this implicit contract will be invalidated with PMD 7.0.0. We now introduce more fine-grained distinctions between the type of compatibility support we guarantee for our libraries, and ways to make them explicit to clients of PMD.

.internal packages and @InternalApi annotation

Internal API is meant for use only by the main PMD codebase. Internal types and methods may be modified in any way, or even removed, at any time.

Any API in a package that contains an .internal segment is considered internal. The @InternalApi annotation will be used for APIs that have to live outside of these packages, e.g. methods of a public type that shouldn’t be used outside of PMD (again, these can be removed anytime).

@ReservedSubclassing

Types marked with the @ReservedSubclassing annotation are only meant to be subclassed by classes within PMD. As such, we may add new abstract methods, or remove protected methods, at any time. All published public members remain supported. The annotation is not inherited, which means a reserved interface doesn’t prevent its implementors to be subclassed.

@Experimental

APIs marked with the @Experimental annotation at the class or method level are subject to change. They can be modified in any way, or even removed, at any time. You should not use or rely on them in any production code. They are purely to allow broad testing and feedback.

@Deprecated

APIs marked with the @Deprecated annotation at the class or method level will remain supported until the next major release, but it is recommended to stop using them.

Small Changes and cleanups XPath 3.1 support

Support for XPath versions 1.0, 1.0-compatibility was removed, support for XPath 2.0 is deprecated. The default (and only) supported XPath version is now XPath 3.1. This version of the XPath language is mostly identical to XPath 2.0.

Notable changes:

Node stream API for AST traversal

This version includes a powerful API to navigate trees, similar in usage to the Java 8 Stream API:

node.descendants(ASTMethodCall.class)
    .filter(m -> "toString".equals(m.getMethodName()))
    .map(m -> m.getQualifier())
    .filter(q -> TypeTestUtil.isA(String.class, q))
    .foreach(System.out::println);

A pipeline like shown here traverses the tree lazily, which is more efficient than traversing eagerly to put all descendants in a list. It is also much easier to change than the old imperative way.

To make this API as accessible as possible, the Node interface has been fitted with new methods producing node streams. Those methods replace previous tree traversal methods like Node#findDescendantsOfType. In all cases, they should be more efficient and more convenient.

See NodeStream for more details.

Contributors: Clément Fournier (@oowekyala)

Metrics framework

The metrics framework has been made simpler and more general.

Testing framework Language Lifecycle and Language Properties

The documentation page has been updated: Adding a new language with JavaCC and Adding a new language with ANTLR

Related issue: [core] Language lifecycle (#3782)

API changes 7.0.0-rc3 7.0.0-rc2 7.0.0-rc1 6.55.0

Go

Java

6.54.0

PMD CLI

Deprecated APIs

For removal

Internal APIs

Experimental APIs

6.53.0

Deprecated APIs

For removal

These classes / APIs have been deprecated and will be removed with PMD 7.0.0.

6.52.0

PMD CLI

CPD CLI

Linux run.sh parameters

Deprecated API

6.51.0

No changes.

6.50.0

CPD CLI

6.49.0

Deprecated API

6.48.0

CPD CLI

Rule Test Framework

Deprecated API

Experimental APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.47.0

No changes.

6.46.0

Deprecated ruleset references

Ruleset references with the following formats are now deprecated and will produce a warning when used on the CLI or in a ruleset XML file:

Use the explicit forms of these references to be compatible with PMD 7.

Deprecated API

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.45.0

Experimental APIs

6.44.0

Deprecated API

Experimental APIs

6.43.0

Deprecated API

Some API deprecations were performed in core PMD classes, to improve compatibility with PMD 7.

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

Changed API

It is now forbidden to report a violation:

Note that the message is set from the XML rule declaration, so this is only relevant if you instantiate rules manually.

RuleContext now requires setting the current rule before calling apply. This is done automatically by RuleSet#apply and such. Creating and configuring a RuleContext manually is strongly advised against, as the lifecycle of RuleContext will change drastically in PMD 7.

6.42.0

No changes.

6.41.0

Command Line Interface

The command line options for PMD and CPD now use GNU-syle long options format. E.g. instead of -rulesets the preferred usage is now --rulesets. Alternatively one can still use the short option -R. Some options also have been renamed to a more consistent casing pattern at the same time (--fail-on-violation instead of -failOnViolation). The old single-dash options are still supported but are deprecated and will be removed with PMD 7. This change makes the command line interface more consistent within PMD and also less surprising compared to other cli tools.

The changes in detail for PMD:

old option new option -rulesets --rulesets (or -R) -uri --uri -dir --dir (or -d) -filelist --file-list -ignorelist --ignore-list -format --format (or -f) -debug --debug -verbose --verbose -help --help -encoding --encoding -threads --threads -benchmark --benchmark -stress --stress -shortnames --short-names -showsuppressed --show-suppressed -suppressmarker --suppress-marker -minimumpriority --minimum-priority -property --property -reportfile --report-file -force-language --force-language -auxclasspath --aux-classpath -failOnViolation --fail-on-violation --failOnViolation --fail-on-violation -norulesetcompatibility --no-ruleset-compatibility -cache --cache -no-cache --no-cache

The changes in detail for CPD:

old option new option --failOnViolation --fail-on-violation -failOnViolation --fail-on-violation --filelist --file-list 6.40.0

Experimental APIs

6.39.0

No changes.

6.38.0

No changes.

6.37.0

PMD CLI

Experimental APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.36.0

No changes.

6.35.0

Deprecated API

6.34.0

No changes.

6.33.0

No changes.

6.32.0

Experimental APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.31.0

Deprecated API

Experimental APIs

6.30.0

Deprecated API

Around RuleSet parsing

Around the PMD class

Many classes around PMD’s entry point (PMD) have been deprecated as internal, including:

Miscellaneous

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.29.0

No changes.

6.28.0

Deprecated API

For removal

6.27.0

Deprecated API

For removal

6.26.0

Deprecated API

For removal

6.25.0

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

For removal

6.24.0

Deprecated APIs

Experimental APIs

Note: Experimental APIs are identified with the annotation Experimental, see its javadoc for details

6.23.0

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

In ASTs

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the Apex, Javascript, PL/SQL, Scala and Visualforce ASTs:

These deprecations are added to the following language modules in this release. Please look at the package documentation to find out the full list of deprecations.

These deprecations have already been rolled out in a previous version for the following languages:

Outside of these packages, these changes also concern the following TokenManager implementations, and their corresponding Parser if it exists (in the same package):

In the Java AST the following attributes are deprecated and will issue a warning when used in XPath rules:

For removal

6.22.0

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

For removal

In ASTs (JSP)

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the JSP AST (with other languages to come):

Please look at net.sourceforge.pmd.lang.jsp.ast to find out the full list of deprecations.

In ASTs (Velocity)

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the VM AST (with other languages to come):

Please look at net.sourceforge.pmd.lang.vm.ast to find out the full list of deprecations.

PLSQL AST

The production and node ASTCursorBody was unnecessary, not used and has been removed. Cursors have been already parsed as ASTCursorSpecification.

6.21.0

Deprecated APIs

Internal API

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

For removal

6.20.0

No changes.

6.19.0

Deprecated APIs

For removal

Internal APIs

6.18.0

Changes to Renderer

Deprecated APIs

For removal

Internal APIs

Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.

6.17.0

No changes.

6.16.0

Deprecated APIs

Reminder: Please don’t use members marked with the annotation InternalApi, as they will likely be removed, hidden, or otherwise intentionally broken with 7.0.0.

In ASTs

As part of the changes we’d like to do to AST classes for 7.0.0, we would like to hide some methods and constructors that rule writers should not have access to. The following usages are now deprecated in the Java AST (with other languages to come):

Please look at net.sourceforge.pmd.lang.java.ast to find out the full list of deprecations.

6.15.0

Deprecated APIs

For removal

6.14.0

No changes.

6.13.0

Command Line Interface

The start scripts run.sh, pmd.bat and cpd.bat support the new environment variable PMD_JAVA_OPTS. This can be used to set arbitrary JVM options for running PMD, such as memory settings (e.g. PMD_JAVA_OPTS=-Xmx512m) or enable preview language features (e.g. PMD_JAVA_OPTS=--enable-preview).

The previously available variables such as OPTS or HEAPSIZE are deprecated and will be removed with PMD 7.0.0.

Deprecated API

6.12.0

No changes.

6.11.0 6.10.0

Properties framework

The properties framework is about to get a lifting, and for that reason, we need to deprecate a lot of APIs to remove them in 7.0.0. The proposed changes to the API are described on the wiki

Changes to how you define properties

Here’s an example:

// Before 7.0.0, these are equivalent:
IntegerProperty myProperty = new IntegerProperty("score", "Top score value", 1, 100, 40, 3.0f);
IntegerProperty myProperty = IntegerProperty.named("score").desc("Top score value").range(1, 100).defaultValue(40).uiOrder(3.0f);

// They both map to the following in 7.0.0
PropertyDescriptor<Integer> myProperty = PropertyFactory.intProperty("score").desc("Top score value").require(inRange(1, 100)).defaultValue(40);

You’re highly encouraged to migrate to using this new API as soon as possible, to ease your migration to 7.0.0.

Architectural simplifications

Changes to the PropertyDescriptor interface

Deprecated APIs

For internalization

For removal

All these are deprecated because those nodes may declare several variables at once, possibly
with different types (and obviously with different names). They both implement `Iterator<`<a href="https://docs.pmd-code.org/apidocs/pmd-java/7.0.0-rc3/net/sourceforge/pmd/lang/java/ast/ASTVariableDeclaratorId.html#"><code>ASTVariableDeclaratorId</code></a>`>`
though, so you should iterate on each declared variable. See [#910](https://github.com/pmd/pmd/issues/910).
6.9.0

No changes.

6.8.0 6.7.0 6.5.0 6.4.0 6.2.0 6.1.0 6.0.1

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4