Add new java printer

[stephweissm]

References to other Issues or PRs

Brief description of what is fixed or changed

JavaScript looks supported. But there is no printer for Java.

Other comments

Release Notes

• printing
  • Code printer for Java

[sympy-bot]

:white_check_mark:

Hi, I am the SymPy bot. I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

Your release notes are in good order.

Here is what the release notes will look like:

• printing
  • Code printer for Java (#26522 by @stephweissm)

This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13.

Click here to see the pull request description that was parsed.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->


#### Brief description of what is fixed or changed
JavaScript looks supported. But there is no printer for Java.

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers. Formerly, `log(-x)` incorrectly gave `-log(x)`.

* physics.units
  * Corrected a semantical error in the conversion between volt and statvolt which
    reported the volt as being larger than the statvolt.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
* printing
  * Code printer for Java
<!-- END RELEASE NOTES -->

[sympy-bot]

🟠

Hi, I am the SymPy bot. I've noticed that some of your commits add or delete files. Since this is sometimes done unintentionally, I wanted to alert you about it.

This is an experimental feature of SymPy Bot. If you have any feedback on it, please comment at https://github.com/sympy/sympy-bot/issues/75.

The following commits add new files:

• 04e23cf5ffd6621c563298ece118bf1ad7d360c1:
  • sympy/printing/java.py
• 2f27c1b8450fbef83c77badae4b4178f9b753825:
  • sympy/printing/tests/test_java.py

If these files were added/deleted on purpose, you can ignore this message.

[sylee957]

Generally, Java and Javascript is not very common, shares nothing common in history, and maintained by different entities (Oracle and W3C), and does not share much things in common, so it may not be a good idea to create superclass printers.

I think that you need to add comprehensive test cases. It's hard to believe that it can generate generally correct code for Java, unless we can read the outputs.

[bjodah]

I think it is wise to reuse the names of the math functions (which are the same between Javascript and Java I believe). It does not need to use a subclass (and it doesn't look like it's an abstract one? so that would need to be renamed anyhow).

And yes, I think more tests are needed. Did you try to get the tests in test_algorithms to pass? (the choice of supported math functions lead me to believe that): https://github.com/sympy/sympy/blob/ab88a7dbf0e79906c43d674f39d320b19156386e/sympy/codegen/tests/test_algorithms.py#L136

If so, it would be great if we could test a full java compilation & execution on the CI-server (we already do this for C). I see that some math functions are still missing, perhaps we should add those too? log1p comes to mind.

We could duplicate the _print_Pow method, but I would be curious to see if we could even move that into codeprinter.py instead, and rely on e.g. _print_Cbrt returning NotImplemented (but I think that should be a separate PR later in that case).

[asmeurer]

If the math libraries are the same then what will be the actual functional difference? If the two are extremely similar, we could just have a single class with a flag to switch between the two. Or just document that for the purposes of what is implemented, jscode can be used with Java.

[bjodah]

I'm not personally a fan of having a flag which changes the behavior of methods of a class, I much rather have two distinctly named classes (their relation, i.e. one being the child of the other, or them both sharing a common parent class is to be considered an implementation detail in my opinion).

Math constants are spelled differently for one. I see inf in this PR, Java's Double.NaN also comes to mind. Java also supports both single and double precision floats, JavaScript only the latter.

But some math constants are spelled the same way, e.g. Math.pi.

Integer division differs between the two, since JavaScript doesn't really have a first class integer type.

If we want to support special functions, I guess we could default to Apache commons math library for Java. But that can of course wait to a later date.

[asmeurer]

Well if they're only incidentally similar, I would actually go the other route and not have the two share any code in common at all. It's not a big deal to duplicate the code across two different files, and it would lead to less confusion and mistakes to have them be separate.