Community
Participate
Working Groups
[hovering] Hover on client code should show the new 'since' deprecation value.
Example: @Deprecated(since="2.0") public void dontUseMe() { }
Created attachment 271335 [details] Attachment showing the since value on usage of deprecated function upon hover
I have not been able to reproduce this issue. Attached a screenshot showing the since value on a deprecated function. If you still find the issue, please provide steps to reproduce this issue
Created attachment 271336 [details] Attachment showing the since value on deprecated function upon hover
I cannot reproduce the issue with latest master and R4_7.
Don't suppress the warning and you will see the problem. So, most likely something that JDT Core needs to add to the warning message.
The bug is about the message from compiler problem (not the Javadoc hover).
Changed the bug title. Note that this requires new API (IProblem).
(In reply to Stephan Herrmann from comment #8) > Changed the bug title. > > Note that this requires new API (IProblem). Why is that? The compiler already recognizes @Deprecated(forRemoval=true) and issues a different message. Why can't it do it for the @since tag without adding new API?
(In reply to Dani Megert from comment #9) > (In reply to Stephan Herrmann from comment #8) > > Changed the bug title. > > > > Note that this requires new API (IProblem). > > Why is that? The compiler already recognizes @Deprecated(forRemoval=true) > and issues a different message. Why can't it do it for the @since tag > without adding new API? It requires adding new API constants to IProblem. The messages relating to "forRemoval" are IProblem.UsingTerminallyDeprecatedType ff. @Deprecated#since (not @since :) ) is independent from "forRemoval", for each location (Type, Method, Constructor, Field) we'd effectively need 4 IProblem constants (i.e., 2 in addition to what we already have), for each combination of forRemoval and since. Corresponding messages for illustration: 5 = The type {0} is deprecated 1400 = The type {0} has been deprecated and marked for removal xxxx = The type {0} has been deprecated since {1} and marked for removal yyyy = The type {0} is deprecated since {1} ------------- TL;DR: I'm requesting approval for adding new API in 4.7.2 :) ------------- If clients like JDT/UI reference any of the old constants relating to deprecation, they should recognize that the new constants are refinements of existing problems, otherwise this could cause loss of functionality. (First quick search didn't yield any occurrences in JDT/UI, though).
(In reply to Stephan Herrmann from comment #10) > TL;DR: I'm requesting approval for adding new API in 4.7.2 :) I'm fine to approve that, but maybe we can just move it to 4.7.3?
(In reply to Dani Megert from comment #11) > (In reply to Stephan Herrmann from comment #10) > > TL;DR: I'm requesting approval for adding new API in 4.7.2 :) > > I'm fine to approve that, but maybe we can just move it to 4.7.3? perfect
New Gerrit change created: https://git.eclipse.org/r/115765
(In reply to Eclipse Genie from comment #13) > New Gerrit change created: https://git.eclipse.org/r/115765 The fix grew a bit larger than expected, because some more infra structure ground work was needed. The compiler was not storing any @Deprecated annotation if !CompilerOptions.storeAnnotations, which also affects the previously implemented addition regarding forRemoval. To resolve this several locations now check: - are we at 9 or greater? - do we have a @Deprecated annotation? - are we configured to drop annotations? If yes to all, then force storing this @Deprecated annotation. This affects both source Annotations and their binary versions in ClassFileReader, MethodInfo and FieldInfo. The latter also remember the class file version, now, for minimal impact of this change. The additional flag "forceStore" in setAnnotations() et al spreads into lots of locations.
Gerrit change https://git.eclipse.org/r/115765 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=67d6195b2e1eca85cb02928c65c7f9577967fe35
(In reply to Eclipse Genie from comment #15) > Gerrit change https://git.eclipse.org/r/115765 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=67d6195b2e1eca85cb02928c65c7f9577967fe35 Released for 4.8 M5. Ticket remains open for: - backport to 4.7.3 after more testing / review - investigating strange setting of AnnotationTerminallyDeprecated in BTB, introduced by bug 517326
This change causes unexpected compile errors in 1.4 projects. 1. Start new workspace 2. Install 1.4 JRE 3. Import org.eclipse.jdt.ui.examples.javafamily from the jdt.ui repo ==> The type java.lang.Deprecated cannot be resolved. It is indirectly referenced from required .class files ExampleProjectCreationOperation.java /org.eclipse.jdt.ui.examples.projects/examples/org/eclipse/jdt/internal/ui/exampleprojects Reverting the "fix" fixes the problem. This must be fixed for M5.
(In reply to Dani Megert from comment #17) > This change causes unexpected compile errors in 1.4 projects. > > 1. Start new workspace > 2. Install 1.4 JRE > 3. Import org.eclipse.jdt.ui.examples.javafamily from the jdt.ui repo > > ==> > > The type java.lang.Deprecated cannot be resolved. It is indirectly > referenced from required .class files > ExampleProjectCreationOperation.java > /org.eclipse.jdt.ui.examples.projects/examples/org/eclipse/jdt/internal/ui/ > exampleprojects > > Reverting the "fix" fixes the problem. > > This must be fixed for M5. Looking into this now.
Reproduced. BTW: I had problems configured my 1.4 JRE, because I only have a linux 32 bit version (since that's what I used when 1.4 was current), which is no longer recognized on my 64 bit box (can't execute bin/java). Any hints on where I can download 64 bit versions of 1.4? If any?
New Gerrit change created: https://git.eclipse.org/r/115899
(In reply to Eclipse Genie from comment #20) > New Gerrit change created: https://git.eclipse.org/r/115899 This fixes the issue for me, test will follow soon. In one place I was asking getAnnotations() outside a compliance check, not expecting that a javadoc @deprecated tag would set TagBits.AnnotationDeprecated.
(In reply to Stephan Herrmann from comment #19) > Reproduced. > > BTW: I had problems configured my 1.4 JRE, because I only have a linux 32 > bit version (since that's what I used when 1.4 was current), which is no > longer recognized on my 64 bit box (can't execute bin/java). > Any hints on where I can download 64 bit versions of 1.4? If any? http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase14-419411.html
(In reply to Dani Megert from comment #22) > (In reply to Stephan Herrmann from comment #19) > > Reproduced. > > > > BTW: I had problems configured my 1.4 JRE, because I only have a linux 32 > > bit version (since that's what I used when 1.4 was current), which is no > > longer recognized on my 64 bit box (can't execute bin/java). > > Any hints on where I can download 64 bit versions of 1.4? If any? > > http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive- > downloads-javase14-419411.html Thanks! Creating a test requires more work, because the bug can only be triggered if you compile agains JRE 1.4 but reference a class file that references java.lang.Deprecated (which implies the reported error is "correct" - still I agree it is not nice).
(In reply to Dani Megert from comment #22) > (In reply to Stephan Herrmann from comment #19) > > Reproduced. > > > > BTW: I had problems configured my 1.4 JRE, because I only have a linux 32 > > bit version (since that's what I used when 1.4 was current), which is no > > longer recognized on my 64 bit box (can't execute bin/java). > > Any hints on where I can download 64 bit versions of 1.4? If any? > > http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive- > downloads-javase14-419411.html Unfortunately, neither .bin nor .rpm.bin can be installed on a modern system, aborts with: Extracting... ./install.sfx.10039: 1: ./install.sfx.10039: ��: not found ./install.sfx.10039: 1: ./install.sfx.10039: ELF2�▒@@H�@8@@@@@���@�@▒▒@@��������P: not found ./install.sfx.10039: 2: ./install.sfx.10039: Syntax error: "(" unexpected Done.
Gerrit change https://git.eclipse.org/r/115899 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=81eb56e192caae0ae3469113ae4e972b6f5341a3
Test released via https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=ff655504c93c01dd0b3ca79d794942dabc7dc0ef This test is a bit crude: I wanted to place this in the compiler.regression suite, but there we don't have the means to compile against a specific JRE (only at specific compliance). I quickly invented a mechanism for hiding a type from the compiler. Test & fix re comment 17 have been released for 4.8 M5. Resetting status to previous.
New Gerrit change created: https://git.eclipse.org/r/115909
(In reply to Eclipse Genie from comment #27) > New Gerrit change created: https://git.eclipse.org/r/115909 I found and fixed another omission: when overriding deprecated methods (warning disabled by default) the warning did not show the since value.
(In reply to Stephan Herrmann from comment #16) > - investigating strange setting of AnnotationTerminallyDeprecated in BTB, > introduced by bug 517326 Moved to new bug 530206
(In reply to Stephan Herrmann from comment #28) > (In reply to Eclipse Genie from comment #27) > > New Gerrit change created: https://git.eclipse.org/r/115909 > > I found and fixed another omission: when overriding deprecated methods > (warning disabled by default) the warning did not show the since value. On Jenkins test now consistently fail with Unexpected standard output for invocation with arguments ["/tmp/comptest/run.1516743234051/regression/src2/Y.java" -extdirs "/tmp/comptest/run.1516743234051/lib:/tmp/comptest/run.1516743234051/regression/src1" -sourcepath "/tmp/comptest/run.1516743234051/regression/src1" -1.5 -g -preserveAllLocals -verbose -proceedOnError -referenceInfo -d "/tmp/comptest/run.1516743234051/regression" ]. ----------- Expected ------------ [parsing ---OUTPUT_DIR_PLACEHOLDER---/src2/Y.java - #1/1]\n [parsing ---OUTPUT_DIR_PLACEHOLDER---/src1/X.java - #2/2]\n [reading java/lang/Object.class]\n [analyzing ---OUTPUT_DIR_PLACEHOLDER---/src2/Y.java - #1/2]\n [writing Y.class - #1]\n [completed ---OUTPUT_DIR_PLACEHOLDER---/src2/Y.java - #1/2]\n [analyzing ---OUTPUT_DIR_PLACEHOLDER---/src1/X.java - #2/2]\n [reading my/pkg/Zork.class]\n [writing X.class - #2]\n [completed ---OUTPUT_DIR_PLACEHOLDER---/src1/X.java - #2/2]\n [2 units compiled]\n [2 .class files generated]\n ------------ but was ------------ [parsing /tmp/comptest/run.1516743234051/regression/src2/Y.java - #1/1]\n [reading X.class]\n [reading java/lang/Object.class]\n [analyzing /tmp/comptest/run.1516743234051/regression/src2/Y.java - #1/1]\n [writing Y.class - #1]\n [completed /tmp/comptest/run.1516743234051/regression/src2/Y.java - #1/1]\n [1 unit compiled]\n [1 .class file generated]\n Running locally I cannot see the error, nor do I have an idea what that failure has to do with my change.
(In reply to Stephan Herrmann from comment #30) > (In reply to Stephan Herrmann from comment #28) > > (In reply to Eclipse Genie from comment #27) > > > New Gerrit change created: https://git.eclipse.org/r/115909 > > > > I found and fixed another omission: when overriding deprecated methods > > (warning disabled by default) the warning did not show the since value. > > On Jenkins test now consistently fail with should mention the test: BatchCompilerTest.test025()
Verified in eclipse-SDK-I20180123-2000-win32-x86_64 that the problem from comment 17 is fixed. Thanks!
(In reply to Stephan Herrmann from comment #31) > (In reply to Stephan Herrmann from comment #30) > > (In reply to Stephan Herrmann from comment #28) > > > (In reply to Eclipse Genie from comment #27) > > > > New Gerrit change created: https://git.eclipse.org/r/115909 > > > > > > I found and fixed another omission: when overriding deprecated methods > > > (warning disabled by default) the warning did not show the since value. > > > > On Jenkins test now consistently fail with > > should mention the test: BatchCompilerTest.test025() Seeing that this also affects the M5 candidate build [1] I investigated further and found that this only happens when running DeprecatedTests & BatchCompilerTest within the same execution => lack of isolation between tests, not a problem in main code. I'm on it. [1] http://download.eclipse.org/eclipse/downloads/drops4/I20180124-2000/testResults.php
New Gerrit change created: https://git.eclipse.org/r/116029
(In reply to Eclipse Genie from comment #34) > New Gerrit change created: https://git.eclipse.org/r/116029 Several tests place their jar files into LIB_DIR, BatchCompilerTest.test025() puts all of LIB_DIR into -extdir => any of the former tests may influence test025(). To add insult to missing isolation, DeprecatedTest.test008a and BatchCompilerTest.test025 both reference class X from the default package => boom. Solution attempt: *always* wipe LIB_DIR during tearDown().
(In reply to Stephan Herrmann from comment #35) > (In reply to Eclipse Genie from comment #34) > > New Gerrit change created: https://git.eclipse.org/r/116029 > > Several tests place their jar files into LIB_DIR, > BatchCompilerTest.test025() puts all of LIB_DIR into -extdir => any of the > former tests may influence test025(). To add insult to missing isolation, > DeprecatedTest.test008a and BatchCompilerTest.test025 both reference class X > from the default package => boom. > > Solution attempt: *always* wipe LIB_DIR during tearDown(). Tests are green. Waiting for master to be re-opened after M5 is declared.
Gerrit change https://git.eclipse.org/r/115909 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=6c5635722c92429933514f7117de3f83f298ef2d
Gerrit change https://git.eclipse.org/r/116029 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=77243bbcfe3ea935bddfbf047e794a3d6a6483b2
Released for 4.8 M6: (In reply to Eclipse Genie from comment #37) > Gerrit change https://git.eclipse.org/r/115909 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=6c5635722c92429933514f7117de3f83f298ef2d Fixed the case of overriding a @Deprecated/since method. (In reply to Eclipse Genie from comment #38) > Gerrit change https://git.eclipse.org/r/116029 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=77243bbcfe3ea935bddfbf047e794a3d6a6483b2 Test isolation to prevent failures in BatchCompilerTest.
A few comments / questions while I'm preparing a squashed back port candidate: API tools gives errors on the new constants in IProblem, I guess I should add API filters, but am not sure which way to go: (1) change @since from 3.14 to 3.13 and add filter against minor version update in Manifest, or (2) keep @since at 3.14 and add filters for all new constants Due to bug 528108 about 50% of the files had conflicts during cherry pick, which then triggered EGit bug 441149. This implies that a significant amount of error-prone manual work was involved. Just saying. If we back port we should probably include a (trivial) fix for bug 530600 to avoid loss of functionality.
New Gerrit change created: https://git.eclipse.org/r/116526
Mmhh, RunAllJava9Tests locally give 4-5 failures, and this happens on head of R4_7_maintenance even before the change from this bug: ModuleBuilderTests.testAutoModule4 GenericRegressionTest_9.testBug488663_005 ModuleCompilationTests.testBug500170b ASTConverter9Test.testBug514417 ModuleCompilationTests.testBug519922 Some of this are known test issues, plus bug 500170.
Status: On Jenkins all tests pass (because R4_7_maintenance doesn't yet test on Java 9) A patch-under-test exists in bug 530600. Patch here is larger than may have been expected, because the compiler did not have the necessary details of standard annotation @Deprecated in all situations. In that light the fix here could potentially contribute to bug 529282 (NPE in binary annotation details), perhaps by triggering a buggy situation more frequently than before. I have not yet added any API filters (see comment 40). If anyone wants to comment/review the back-port, now would be a good time.
Gerrit change https://git.eclipse.org/r/116526 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=bf3881160a8c2cad0003a22cceb7074496967f3b
At a closer look I could find no theory how bug 529282 could possibly be caused by changes in this bug, so ... (In reply to Eclipse Genie from comment #44) > Gerrit change https://git.eclipse.org/r/116526 was merged to > [R4_7_maintenance]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=bf3881160a8c2cad0003a22cceb7074496967f3b ... I released the fix for 4.7.3.
Verified for Eclipse Oxygen.3 (4.7.3) with Build id: M20180214-1700
Verified for 4.8 M6 with build I20180305-2000