Guava cannot be built with old javac's (1.5) #364
Comments
|
Original comment posted by kevinb@google.com on 2010-05-29 at 03:31 PM Mikael, I'm not sure why you want to build using JDK 5. The best-practice is to always build with the newest JDK Status: |
|
Original comment posted by kevinb@google.com on 2010-07-16 at 10:00 PM Something is rotten in Denmark. (No offense, Danes.) I'm observing 5u21 (and u22 and u16) to NOT compile certain things that I thought for sure they would. Need to look into this. However, the question still remains as to whether Guava should need to support compiling with old compilers at all. I don't understand why. Status: |
|
Original comment posted by mikael.barbero on 2010-07-17 at 09:07 AM Heaven will direct it ;) I think it is more a lack in tooling support rather than a real need to support old compilers. I was first reporting this bug because I used Eclipse to build guava. The issue is that Java Development Tool of Eclipse does not let me specifying a compiler different from the one specified in the execution environment. It means that if I target JDK5, and then set JDK5 as my build path, Eclipse/JDT will use the compiler from JDK5. My 2 cents to explain why people may want to build Guava with JDK5. |
|
Original comment posted by kevinb@google.com on 2010-07-30 at 03:56 AM (No comment entered for this change.) Labels: - |
|
Original comment posted by kevinb@google.com on 2011-01-27 at 06:15 AM I'm sorry, but I just can't see us spending the time to go backwards in time again. I'm sorry we moved to a source-level JDK6 requirement without realizing it, but... we did. Status: |
|
Original comment posted by kevinb@google.com on 2011-10-24 at 03:28 PM Saw this bug referenced as "a reason not to use Guava." Does everyone understand that Guava is still perfectly usable on JDK 5, it just can't be built using JDK 5, and that part of the reason for that is compiler bugs in JDK 5 whose fixes in 6 were never backported? |
|
Original comment posted by jherico72 on 2011-10-24 at 06:41 PM The issue appears to be a source incompatibility, not a compiler bug. Java 5 does not allow the @Override annotation on initial implementations of interface methods, only on method implementations that override other implementations. The bug is in JDK 6, which does not properly honor the '-source 1.5' command line option, thus masking the fact that the code isn't JDK 5 compatible when building it in JDK 6. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969902 |
|
Original comment posted by kevinb@google.com on 2011-10-27 at 02:17 AM I say again: part of the reason we stopped worrying about being able to compile in JDK 5 is that we were tired of preserving our workarounds for JDK 5 compiler bugs. I don't remember what it was exactly or what became of it. I have still never managed to understand why being able to build Guava with an old JDK is even important. |
|
Original comment posted by j...@nwsnet.de on 2011-10-27 at 09:04 AM If I understand comment 8 correctly, that bug needs to be fixed in JDK 6 before one can build JDK 5-compatible releases with it? (Again?) Also, is "latest JDK" already referring to JDK 7? |
|
Original comment posted by jherico72 on 2011-10-27 at 02:18 PM @10: No. You CAN currently build Java 5 compatible releases with a JDK 6 compiler. The bug only makes the code appear to be JDK 5 compatible when it isn't because the JDK 6 compiler fails to generate an error saying the source is not valid Java 5 code when it encounters the invalid (in Java 5) @Override annotations. @9: I personally don't care about Java 5 compatibility anymore. I just think its disingenuous to claim that the reason Guava can't be built in JDK 5 is any kind of compiler bug when its demonstrably a source incompatibility. Yes, the jar can be used on Java 5. No, that doesn't help everyone because some organizations might have both a JDK 5 requirement or mandate as well as a build from source mandate. Such people are always free to fork the source and make it JDK 5 compatible if they really really want to. |
|
Original comment posted by kevinb@google.com on 2011-10-27 at 09:15 PM jheric, you don't even know what the compiler bugs I'm referring to are, yet you're calling me disingenous. I am not here to prove our righteousness to you. I am saying that we made a decision not to support compiling in JDK 5. You don't have to love the decision. But I saw no harm in mentioning the truth that PART of the reason for that was that we were tired of dealing with a compiler quirk that would work in 1.6 but then bizarrely fail much later when the code went out to Guava. (The one I remember had to do with casting an empty immutable collection, but the specifics don't matter.) Why I'm being chastised for sharing that is beyond me. |
|
Original comment posted by jherico72 on 2011-10-27 at 09:32 PM my apologies, 'disingenuous' was a bit harsh. I incorrectly assumed you were talking about the Sun bug I referenced which I originally opened as a result of this Guava issue. |
|
Original comment posted by sahendrickson on 2012-12-23 at 08:44 PM Not to beat a dead horse... but should Guava .jar files be compatible with JDK 1.5? It appears that the latest release (14-rc1) is not. If not, okay, but wanted to double check. |
|
Original comment posted by neveue on 2012-12-24 at 09:54 AM Since Guava 12, Guava requires JDK6: http://code.google.com/p/guava-libraries/wiki/Release12 A jdk5 backport branch was created: http://repo2.maven.org/maven2/com/google/guava/guava-jdk5/13.0/ I haven't used it, since I'm on Java 7, but I would look into it if I were stuck using Java 5. |
gissuebot
added
type=defect
Original issue created by mikael.barbero on 2010-05-29 at 07:55 AM
Dear guava developers,
It seems that Guava is using Java 6 only @Override annotations. It appears 14 times in r34 (it
seems it started in r09).
Maybe this is known and ignored as it should not break binary compatibility but it IMHO, it
should stick to Java 5 SDK. Here is the list of files being concerned:
* The method apply(Character) of type CharMatcher must override a superclass method
CharMatcher.java com/google/common/base @ line 1126
* The method getNextExpirable() of type CustomConcurrentHashMap<K,V>.NullExpirable must
override a superclass method CustomConcurrentHashMap.java com/google/common/collect
@ line 621
* The method getPreviousExpirable() of type CustomConcurrentHashMap<K,V>.NullExpirable
must override a superclass method CustomConcurrentHashMap.java
com/google/common/collect @ line 628
* The method getWriteTime() of type CustomConcurrentHashMap<K,V>.NullExpirable must
override a superclass method CustomConcurrentHashMap.java com/google/common/collect
@ line 614
* The method setNextExpirable(CustomConcurrentHashMap.Expirable) of type
CustomConcurrentHashMap<K,V>.NullExpirable must override a superclass method
CustomConcurrentHashMap.java com/google/common/collect @ line 625
* The method setPreviousExpirable(CustomConcurrentHashMap.Expirable) of type
CustomConcurrentHashMap<K,V>.NullExpirable must override a superclass method
CustomConcurrentHashMap.java com/google/common/collect @ line 632
* The method setWriteTime(long) of type CustomConcurrentHashMap<K,V>.NullExpirable must
override a superclass method CustomConcurrentHashMap.java com/google/common/collect
@ line 618
* The method addListener(Runnable, Executor) of type ForwardingListenableFuture<V> must
override a superclass method ForwardingListenableFuture.java
com/google/common/util/concurrent @ line 44
* The method valueComparator() of type ForwardingSortedSetMultimap<K,V> must override a
superclass method ForwardingSortedSetMultimap.java com/google/common/collect @ line
58
* The method apply(I) of type new Function<I,ListenableFuture<O>>(){} must override a
superclass method Futures.java com/google/common/util/concurrent @ line 315
* The method compare(Object, Object) of type Ordering<T>.ArbitraryOrdering must override a
superclass method Ordering.java com/google/common/collect @ line 214
* The method hasNext() of type Sets.PowerSet<E>.BitFilteredSetIterator<E> must override a
superclass method Sets.java com/google/common/collect @ line 1061
* The method next() of type Sets.PowerSet<E>.BitFilteredSetIterator<E> must override a
superclass method Sets.java com/google/common/collect @ line 1065
* The method newThread(Runnable) of type new ThreadFactory(){} must override a superclass
method ThreadFactoryBuilder.java com/google/common/util/concurrent @ line 155
Best regards,
Mikael
The text was updated successfully, but these errors were encountered: