33133-94684a15133src/test/java/com/jcabi/aspects/ImmutableTest.java57-5830DEVunknownunknown@0pdd.com
The test is disabled since in Java final arrays can still be modified (bloody Java!)
24233-e5af3af333src/main/java/com/jcabi/aspects/Immutable.java65-6830DEVunknownunknown@0pdd.com
Let's prevent modifications to arrays having this annotation, somehow. Perhaps we can create an aspect that will throw an exception should something try to write into the array. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=157031
unknown61-1692fcb261src/main/java/com/jcabi/aspects/aj/MethodValidator.java194-19730DEVunknownunknown@0pdd.com
It's a temporary design, which enables only NotNull, Valid, and Pattern annotations. In the future we should use JSR-303 Validator, when they implement validation of values (see their appendix C).
321-b78971091src/main/java/com/jcabi/aspects/Quietly.java44-4730DEVunknownunknown@0pdd.com
This annotation has to be on methods returning void only. A compile-time APT processor needs to be created that will verify that only void methods have @Quietly annotations. In runtime it should throw an exception before executing of method body, if its return type is not void.
4132-9b5b2ac832src/main/java/com/jcabi/aspects/Quietly.java44-4830DEVunknownunknown@0pdd.com
This annotation has to be on methods returning void only. We already have runtime checking of the return type, and any methods annotated with @Quietly that don't throw void throws an exception. Let's create a compile-time APT processor needs to be created that will verify that only void methods have @Quietly annotations.
unknown41-28606be441src/main/java/com/jcabi/aspects/aj/MethodAsyncRunner.java51-5530unknownunknown@0pdd.com
It is meaningless for methods covered by this class if they return anything other than void or {@link java.util.concurrent.Future}. Currently, null is returned when the annotated method returns any other type. Let's make it throw an exception, instead, similar to how {@link QuietExceptionsLogger} does it.
IMPunknown41-c2ba08a741src/main/java/com/jcabi/aspects/Async.java54-5630unknownunknown@0pdd.com
We should create a compile-time APT processor that checks whether methods annotated with {@link Async} return either void or Future. The check should fail if that is not the case.
IMPunknown30-13669aa430src/test/java/com/jcabi/aspects/AsyncTest.java77-7830DEVunknownunknown@0pdd.com
This test is not stable during Maven build, for some reason. Let's fix and enable it.
unknown14-97704c5f14src/main/java/com/jcabi/aspects/aj/MethodCacher.java65-6630DEVunknownunknown@0pdd.com
Split this class into smaller ones so it will have less responsibility and remove PMD.GodClass suppressed warning.
unknown86-2fc54a8a86src/main/java/com/jcabi/aspects/Loggable.java187-18830unknownunknown@0pdd.com
Let's document the usage of this parameter, including its effects and default setting, in the annotation-loggable.apt.vm page.
IMPunknown85-4b96ddcb85src/main/java/com/jcabi/aspects/Loggable.java196-19730unknownunknown@0pdd.com
Let's document the usage of this parameter in the annotation-loggable.apt.vm site page.
IMPunknown87-2655d0cc87src/main/java/com/jcabi/aspects/aj/MethodLogger.java175-17630unknownunknown@0pdd.com
Refactor this method into smaller ones and remove both PMD and Checkstyle suppress.
IMPunknown104-259d589d104src/test/java/com/jcabi/aspects/ImmutableTest.java77-8230unknownunknown@0pdd.com
Assignment is not intersected, that's why this test doesn't work. We simply don't catch the moment when an object is assigned to the private filed of another object. That's why we can't tell when such a mutable class is being used. I think we should introduce a new AspectJ join point in ImmutabilityChecker, which will catch assignments.
IMPunknown109-bb540c79109src/main/java/com/jcabi/aspects/aj/Mnemos.java289-29030unknownunknown@0pdd.com
Add handling of int, long, float, double, char and boolean arrays.
IMPunknown128-1ba0b794128src/test/java/com/jcabi/aspects/ImmutableTest.java68-7330
This test and the next one are ignored because this functionality was removed in #128. It simply didn't work correctly and I didn't manage to reproduce it. I suspect that that the issue appears when one constructor is calling another constructor. Anyway, let's try to investigate and re-implement the functionality again.
IMPYegor Bugayenkoyegor@tpc2.comunknown124-0ed2a036124src/test/java/com/jcabi/aspects/CacheableTest.java57-5830
Make sure that this test runs under Java 8 and remove the Ignore annotation then.
IMPDmitri Pisarenkodp@altruix.counknown169-0e4b9121169src/test/java/com/jcabi/aspects/JSR303Test.java61-6430
When I replaced our own validation with that of hibernate-validator for #34, this test stopped working in openJDK6, but remained working in all the other JDKs we're using on Travis CI. This test should pass without errors.
IMPSuseikawlasowegor@gmail.comunknown167-78e42157167src/main/java/com/jcabi/aspects/aj/ImmutabilityChecker.java65-6830
Inserting correct version/buildnumber here and in other instances where Version.CURRENT is used (not only in this class, but in every class that uses Version.CURRENT) should be covered by a test.
IMPSuseikawlasowegor@gmail.comunknown194-8b58eead194src/main/java/com/jcabi/aspects/aj/MethodValidator.java152-15630
We need to find a way to disable the constraint rule OverridingMethodMustNotAlterParameterConstraints instead of catching the exception. See https://hibernate.atlassian.net/browse/HV-1044 After that don't forget to enable test JSR303Test#overridesMessage()
IMPDmitry Zaytsevdmitry.zaytsev@gmail.com