[jira] [Commented] (LANG-942) Test failure in FastDateParserTest and FastDateFormat_ParserTest when building with JDK8
[
https://issues.apache.org/jira/browse/LANG-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862521#comment-13862521
]
Henri Yandell commented on LANG-942:
Seeing if I understand this right (paraphrasing Bruno):
The code is failing because the order in Java 8's timezone db changed. The
issue is not the test, but that our code is creating a lookup table with four
entries:
Timezone short name (this is unique).
Timezone long name (this isn't unique).
Timezone short w/ daylight saving. (per above)
Timezone long w/ daylight saving. (per above)
The two longs aren't unique, making them bad keys. Stepping away from the Map,
the issue is with the API of the class.
When parsing text that includes a TimeZone's long name, you can't guarantee
there is one answer. Thus we either:
a) Don't offer this feature. Which is easy, remove the two lines from the code
and any tests.
b) Choose one of the options.
c) Return all of them [not really feasible, or useful].
Presumably this bug would also appear on older versions of Java, ie: it's not
something special to the Java 7 to Java 8 transition.
Looking at SimpleDateFormat, it's matchTimeZone method appears to check the
same four items. It behaves differently, returning the first found in the array
rather than the last (as ours does). It would appear that the first one found
is America/New York. Presumably that's the same in Java 7 and 8 (and for all
- I bet they add new ones on the end, not the beginning).
So I think the main issue is in using TimeZone.getAvailableIDs and then
TimeZone.getTimeZone(id). Instead we should be using
java.text.DateFormatSymbols, and calling the getZoneStrings() method (thus (b)
above). We should also not put something in the map if it's already there to
match the first in rather than last in style. This does make this Oracle JDK
specific behaviour, but I suspect this code is the same in the various JDKs as
its typical use of the DateFormatSymbols. Its only our caching and use of a
different API that leads to weirdness.
The odd thing is that none of this suggests that we should see an error. It's a
rare use to get a Date from a formatter, and then ask the formatter exactly
which timezone it used to give you that date. Who cares if it's IET or Michigan
eh? Except we're talking about weird TimeZones and I'm betting that we're
adding a timezone to the map (with IET) that doesn't actually apply to Eastern
Daylight Time during the date we're discussing. Thus the value ends up an hour
off. There's a theoretical bug in the JDK here, except I bet they always put
the normal timezones above the weird ones, meaning the normal ones get chosen.
Hopefully this all sounds sane and not the ramblings of someone who should be
asleep :)
Test failure in FastDateParserTest and FastDateFormat_ParserTest when
building with JDK8
Key: LANG-942
URL: https://issues.apache.org/jira/browse/LANG-942
Project: Commons Lang
Issue Type: Sub-task
Components: lang.time.*
Affects Versions: 3.2
Environment: JDK8
Reporter: Benedikt Ritter
Fix For: 3.2.1, Patch Needed
The following failure is thrown when using JDK 8:
{code}
---
Test set: org.apache.commons.lang3.time.FastDateFormat_ParserTest
---
Tests run: 29, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.315 sec
FAILURE! - in org.apache.commons.lang3.time.FastDateFormat_ParserTest
testParseZone(org.apache.commons.lang3.time.FastDateFormat_ParserTest) Time
elapsed: 0.005 sec FAILURE!
java.lang.AssertionError: expected:Thu Jul 10 22:33:20 CEST 2003 but
was:Thu Jul 10 23:33:20 CEST 2003
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.commons.lang3.time.FastDateParserTest.testParseZone(FastDateParserTest.java:119)
[...]
{code}
It is caused by the following assertion in FastDateParserTest (from which
FastDateFormat_ParserTest inherits):
{code:java}
assertEquals(cal.getTime(), fdf.parse(2003-07-10T16:33:20.000 Eastern
Daylight Time));
{code}
{{FastDateParserTest}} fails with the same error.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (LANG-942) Test failure in FastDateParserTest and FastDateFormat_ParserTest when building with JDK8
[
https://issues.apache.org/jira/browse/LANG-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862524#comment-13862524
]
Benedikt Ritter commented on LANG-942:
--
Setting a link to LANG-462 since it has introduced this bug.
Test failure in FastDateParserTest and FastDateFormat_ParserTest when
building with JDK8
Key: LANG-942
URL: https://issues.apache.org/jira/browse/LANG-942
Project: Commons Lang
Issue Type: Sub-task
Components: lang.time.*
Affects Versions: 3.2
Environment: JDK8
Reporter: Benedikt Ritter
Fix For: 3.2.1, Patch Needed
The following failure is thrown when using JDK 8:
{code}
---
Test set: org.apache.commons.lang3.time.FastDateFormat_ParserTest
---
Tests run: 29, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.315 sec
FAILURE! - in org.apache.commons.lang3.time.FastDateFormat_ParserTest
testParseZone(org.apache.commons.lang3.time.FastDateFormat_ParserTest) Time
elapsed: 0.005 sec FAILURE!
java.lang.AssertionError: expected:Thu Jul 10 22:33:20 CEST 2003 but
was:Thu Jul 10 23:33:20 CEST 2003
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.commons.lang3.time.FastDateParserTest.testParseZone(FastDateParserTest.java:119)
[...]
{code}
It is caused by the following assertion in FastDateParserTest (from which
FastDateFormat_ParserTest inherits):
{code:java}
assertEquals(cal.getTime(), fdf.parse(2003-07-10T16:33:20.000 Eastern
Daylight Time));
{code}
{{FastDateParserTest}} fails with the same error.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (LANG-942) Test failure in FastDateParserTest and FastDateFormat_ParserTest when building with JDK8
[
https://issues.apache.org/jira/browse/LANG-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-942.
--
Resolution: Fixed
Fix Version/s: (was: Patch Needed)
Fixed the way Henri suggested.
{code}
Sendingsrc/changes/changes.xml
Sendingsrc/main/java/org/apache/commons/lang3/time/FastDateParser.java
Transmitting file data ..
Committed revision 1555485.
{code}
Test failure in FastDateParserTest and FastDateFormat_ParserTest when
building with JDK8
Key: LANG-942
URL: https://issues.apache.org/jira/browse/LANG-942
Project: Commons Lang
Issue Type: Sub-task
Components: lang.time.*
Affects Versions: 3.2
Environment: JDK8
Reporter: Benedikt Ritter
Fix For: 3.2.1
The following failure is thrown when using JDK 8:
{code}
---
Test set: org.apache.commons.lang3.time.FastDateFormat_ParserTest
---
Tests run: 29, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.315 sec
FAILURE! - in org.apache.commons.lang3.time.FastDateFormat_ParserTest
testParseZone(org.apache.commons.lang3.time.FastDateFormat_ParserTest) Time
elapsed: 0.005 sec FAILURE!
java.lang.AssertionError: expected:Thu Jul 10 22:33:20 CEST 2003 but
was:Thu Jul 10 23:33:20 CEST 2003
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.commons.lang3.time.FastDateParserTest.testParseZone(FastDateParserTest.java:119)
[...]
{code}
It is caused by the following assertion in FastDateParserTest (from which
FastDateFormat_ParserTest inherits):
{code:java}
assertEquals(cal.getTime(), fdf.parse(2003-07-10T16:33:20.000 Eastern
Daylight Time));
{code}
{{FastDateParserTest}} fails with the same error.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (LANG-938) Build fails with test failures when building with JDK 8
[
https://issues.apache.org/jira/browse/LANG-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-938.
--
Resolution: Fixed
Fix Version/s: (was: Patch Needed)
Subtasks have been resolved. Issue marked as resolved.
Build fails with test failures when building with JDK 8
---
Key: LANG-938
URL: https://issues.apache.org/jira/browse/LANG-938
Project: Commons Lang
Issue Type: Bug
Affects Versions: 3.2
Reporter: Benedikt Ritter
Fix For: 3.2.1
During the vote on Lang 3.2 RC 2, Jörg Schaible pointed out, that the build
fails when using JDK 8 [1]:
{code}
= % ==
Failed tests:
FastDateParserTest.testParseZone:119 expected:Thu Jul 10 22:33:20 CEST
2003 but was:Thu Jul 10 23:33:20 CEST 2003
FastDateFormat_ParserTestFastDateParserTest.testParseZone:119
expected:Thu Jul 10 22:33:20 CEST 2003 but was:Thu Jul 10 23:33:20 CEST
2003
Tests in error:
LocaleUtilsTest.testParseAllLocales:570 » IllegalArgument Invalid locale
forma...
= % ==
{code}
[1] http://markmail.org/message/5mrq4bcnhyfvlvwx
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (LANG-943) Test DurationFormatUtilsTest.testEdgeDuration fails in JDK 1.6, 1.7 and 1.8, BRST time zone
Bruno P. Kinoshita created LANG-943: --- Summary: Test DurationFormatUtilsTest.testEdgeDuration fails in JDK 1.6, 1.7 and 1.8, BRST time zone Key: LANG-943 URL: https://issues.apache.org/jira/browse/LANG-943 Project: Commons Lang Issue Type: Bug Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 12:22:22-0300) Maven home: /opt/java/apache-maven-3.1.1 Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.11.0-14-generic, arch: amd64, family: unix JDK 1.6.0_27, JDK 1.7.0_25, JDK 1.7.0_25 Reporter: Bruno P. Kinoshita While helping testing LANG-942 with JDK1.8 I always got three tests failing, while others had 2. After @britter fixed the issues related to JDK1.8, I continue getting errors with JDK1.8. I decided to vote for [lang] 3.2.1 and test the tag with JDK 1.8 and a few others. However, I'm getting errors with any JDK, 1.6, 1.7 and 1.8 (build 121). Always the same error: Failed tests: DurationFormatUtilsTest.testEdgeDurations:467-assertEqualDuration:562-assertEqualDuration:575 expected:7[7] but was:7[6] I get the same error with JDK 1.6 and the tag 3.1 Since the test is somewhat related to Time Zones (there are some Calendar's, TimeZone.getDefault(), etc), here's my locale and time zone: kinow@chuva:~/java/apache/commons-lang-31$ locale LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= kinow@chuva:~/java/apache/commons-lang-31$ date Sun Jan 5 21:23:05 BRST 2014 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-943) Test DurationFormatUtilsTest.testEdgeDuration fails in JDK 1.6, 1.7 and 1.8, BRST time zone
[ https://issues.apache.org/jira/browse/LANG-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862688#comment-13862688 ] Bruno P. Kinoshita commented on LANG-943: - Build (mvn clean test -e -X) fails for me in Ubuntu Linux 3.11.0-14-generic x86_64, Apache Maven 3.1.1 for: # JDK 1.6.0_27 # Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 12:22:22-0300) Maven home: /opt/java/apache-maven-3.1.1 Java version: 1.6.0_27, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.11.0-14-generic, arch: amd64, family: unix [...] [...] [...] [...] Results : Failed tests: DurationFormatUtilsTest.testEdgeDurations:467-assertEqualDuration:562-assertEqualDuration:575 expected:7[7] but was:7[6] Tests run: 2392, Failures: 1, Errors: 0, Skipped: 4 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 52.186s [INFO] Finished at: Sun Jan 05 21:05:29 BRST 2014 [INFO] Final Memory: 23M/262M [INFO] # JDK 1.7.0_25 # Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 12:22:22-0300) Maven home: /opt/java/apache-maven-3.1.1 Java version: 1.7.0_25, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.11.0-14-generic, arch: amd64, family: unix [...] [...] [...] [...] Results : Failed tests: DurationFormatUtilsTest.testEdgeDurations:467-assertEqualDuration:562-assertEqualDuration:575 expected:7[7] but was:7[6] Tests run: 2392, Failures: 1, Errors: 0, Skipped: 5 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 44.062s [INFO] Finished at: Sun Jan 05 21:10:30 BRST 2014 [INFO] Final Memory: 24M/337M [INFO] --- # JDK 1.8.0b121 # Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 12:22:22-0300) Maven home: /opt/java/apache-maven-3.1.1 Java version: 1.8.0-ea, vendor: Oracle Corporation Java home: /opt/java/jdk1.8.0/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.11.0-14-generic, arch: amd64, family: unix [...] [...] [...] [...] Results : Failed tests: DurationFormatUtilsTest.testEdgeDurations:467-assertEqualDuration:562-assertEqualDuration:575 expected:7[7] but was:7[6] Tests run: 2392, Failures: 1, Errors: 0, Skipped: 5 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 57.890s [INFO] Finished at: Sun Jan 05 21:12:57 BRST 2014 [INFO] Final Memory: 24M/168M [INFO] -- Test DurationFormatUtilsTest.testEdgeDuration fails in JDK 1.6, 1.7 and 1.8, BRST time zone --- Key: LANG-943 URL: https://issues.apache.org/jira/browse/LANG-943 Project: Commons Lang Issue Type: Bug Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 12:22:22-0300) Maven home: /opt/java/apache-maven-3.1.1 Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.11.0-14-generic, arch: amd64, family: unix JDK 1.6.0_27, JDK 1.7.0_25, JDK 1.7.0_25 Reporter: Bruno P. Kinoshita Labels: test-fail, timezone While helping testing LANG-942 with JDK1.8 I always got three tests failing, while others had 2. After @britter fixed the issues related to JDK1.8, I continue getting errors with JDK1.8. I decided to vote for [lang] 3.2.1 and test the tag with JDK 1.8 and a few others. However, I'm getting errors with any JDK, 1.6, 1.7 and 1.8 (build 121). Always the same error: Failed tests: DurationFormatUtilsTest.testEdgeDurations:467-assertEqualDuration:562-assertEqualDuration:575 expected:7[7] but was:7[6] I get the same error with JDK 1.6 and the tag 3.1 Since the test is somewhat related to Time Zones (there are some Calendar's, TimeZone.getDefault(), etc), here's my locale and time zone: kinow@chuva:~/java/apache/commons-lang-31$ locale LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE=en_US.UTF-8
[jira] [Created] (VFS-509) Can't add a FileSystem using the API
Shevek created VFS-509: -- Summary: Can't add a FileSystem using the API Key: VFS-509 URL: https://issues.apache.org/jira/browse/VFS-509 Project: Commons VFS Issue Type: Bug Reporter: Shevek I can't take a StandardFileSystemManager and add a FileSystemProvider using the Java APIs. Well, I can, but I have to use reflection. A FileSystem requires a VfsComponentContext. This is not accessible using public APIs on the FSM or any VfsComponent. Although it has no state, the class is protected, so I can't instantiate one either. Please make enough of the API public that this simple task can be performed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (VFS-509) Can't add a FileSystem using the API
[ https://issues.apache.org/jira/browse/VFS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shevek updated VFS-509: --- Affects Version/s: 2.0 Can't add a FileSystem using the API Key: VFS-509 URL: https://issues.apache.org/jira/browse/VFS-509 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Shevek I can't take a StandardFileSystemManager and add a FileSystemProvider using the Java APIs. Well, I can, but I have to use reflection. A FileSystem requires a VfsComponentContext. This is not accessible using public APIs on the FSM or any VfsComponent. Although it has no state, the class is protected, so I can't instantiate one either. Please make enough of the API public that this simple task can be performed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862727#comment-13862727 ] Shevek commented on VFS-508: Please do NOT apply this patch. What most people don't understand about exceptions is that you DON'T HAVE to catch them. If an exceptional condition has occurred, and you can't handle it elegantly, just propagate it. The condition still occurred. Perhaps you have to change the type of the exception to cross a fixed API boundary, but that's minor. DO NOT hide the exception as a RuntimeException which the programmer is now allowed to be unaware of. Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached) --- Key: VFS-508 URL: https://issues.apache.org/jira/browse/VFS-508 Project: Commons VFS Issue Type: Improvement Reporter: Shant Stepanian Attachments: changeFileSystemToRuntime.patch I'd like to see if we can FileSystemException to inherit from a RuntimeException, and not IOException I searched the JIRA and didn't see any old tickets referring to this, so I'll bring it up here _The reason_ The reason would go back to the whole Runtime vs. Checked exception debate, and I do prefer the RuntimeException argument that with those, you have the choice on whether to declare the try/catch block upon usage, whereas Checked exceptions force that on you In particular, I bring this up because I feel it hurts the usability of the API to have all operations as a checked exception. I recently looked to convert my code from using the regular Java JDK file api to the VFS api, and I found that in a number of places, I now have to add a try/catch block to handle a checked exception where I previously didn't have to (e.g. File.listFiles() vs. FileObject.getChildren(), new File(myFile) vs. VFS.getManager().resolveFile(myFile)) Having one less impediment to migrate would make it easier to adopt for more people. As a frame of reference, Hibernate did make a change like this to convert HibernateException from checked to runtime, and it was fine for them _Patch and Impact of Change_ I've attached a patch of the change - you can see it is very small, and the code still compiles. I ran a test locally and it failed on some of the external-resource-related bits; I can follow up on this, but would like to first get your approval on this ticket before proceeding w/ any more work In terms of client changes - this would only impact clients that happened to explicitly expect an IOException in their catch block, and not directly the FileSystemException. (this affected one piece of code within VFS itself, but could affect clients). But I believe that this still would be a beneficial change, as it would make all clients' code cleaner and make it easier to adopt -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862733#comment-13862733 ] Shant Stepanian commented on VFS-508: - I'd ask if these exceptions that are exposed in much of the current API (specifically in the org.apache.commons.vfs2.VFS and org.apache.commons.vfs2.FileObject classes) truly warrant throwing checked exceptions that programmers must be aware of. However we accomplish this change, whether by changing the base class of FileSystemException or by changing the signatures of the VFS and FileObject classes to not throw checked exceptions, does not matter to me As an example why I don't think many of the calls in these 2 classes warrant checked exceptions, see the first one from my earlier comment: * File.listFiles() vs. FileObject.getChildren() Certainly, something can go wrong if that is called, but I'd argue that in most cases, if you cannot complete a simple getChildren call, that is probably not a recoverable error, as mentioned in Gary's first comment (step 58), and so I should not have to catch an exception for that. (much like we would not catch errors if, say, we run out of memory). Plus, the core Java API does not feel these are worthy of throwing checked exceptions, so I'd ask why these are checked exceptions in VFS This is one example, but I can certainly come up with more if needed Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached) --- Key: VFS-508 URL: https://issues.apache.org/jira/browse/VFS-508 Project: Commons VFS Issue Type: Improvement Reporter: Shant Stepanian Attachments: changeFileSystemToRuntime.patch I'd like to see if we can FileSystemException to inherit from a RuntimeException, and not IOException I searched the JIRA and didn't see any old tickets referring to this, so I'll bring it up here _The reason_ The reason would go back to the whole Runtime vs. Checked exception debate, and I do prefer the RuntimeException argument that with those, you have the choice on whether to declare the try/catch block upon usage, whereas Checked exceptions force that on you In particular, I bring this up because I feel it hurts the usability of the API to have all operations as a checked exception. I recently looked to convert my code from using the regular Java JDK file api to the VFS api, and I found that in a number of places, I now have to add a try/catch block to handle a checked exception where I previously didn't have to (e.g. File.listFiles() vs. FileObject.getChildren(), new File(myFile) vs. VFS.getManager().resolveFile(myFile)) Having one less impediment to migrate would make it easier to adopt for more people. As a frame of reference, Hibernate did make a change like this to convert HibernateException from checked to runtime, and it was fine for them _Patch and Impact of Change_ I've attached a patch of the change - you can see it is very small, and the code still compiles. I ran a test locally and it failed on some of the external-resource-related bits; I can follow up on this, but would like to first get your approval on this ticket before proceeding w/ any more work In terms of client changes - this would only impact clients that happened to explicitly expect an IOException in their catch block, and not directly the FileSystemException. (this affected one piece of code within VFS itself, but could affect clients). But I believe that this still would be a beneficial change, as it would make all clients' code cleaner and make it easier to adopt -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862741#comment-13862741 ] Shevek commented on VFS-508: It's entirely recoverable. An IOException in my networking systems does not cause the application to exit, it just waits and retries; perhaps a router was down. An IOException in my GUI does not cause the entire application to exit. It just causes a particular button press to have failed, and show an error dialog. In order to implement simple behaviour like that, checked exceptions are expected. I spend my life writing distributed networking systems, and shipping them to customers. Errors and exceptions are the rule, not the exception, as it were. In any situation like that, I want to know every possible error that the code can throw. Unchecked exceptions are fine for local hacks, but nothing else. If you really want to see how exceptions need to be handled in distributed systems, I suggest you look at Hystrix. Of course that comes with a thread transition cost every time it's used, so one wants to avoid it where a simpler case will satisfy. Retries are handled using C*'s RetryStrategy. The point of checked exceptions is to allow people to write robust applications. Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached) --- Key: VFS-508 URL: https://issues.apache.org/jira/browse/VFS-508 Project: Commons VFS Issue Type: Improvement Reporter: Shant Stepanian Attachments: changeFileSystemToRuntime.patch I'd like to see if we can FileSystemException to inherit from a RuntimeException, and not IOException I searched the JIRA and didn't see any old tickets referring to this, so I'll bring it up here _The reason_ The reason would go back to the whole Runtime vs. Checked exception debate, and I do prefer the RuntimeException argument that with those, you have the choice on whether to declare the try/catch block upon usage, whereas Checked exceptions force that on you In particular, I bring this up because I feel it hurts the usability of the API to have all operations as a checked exception. I recently looked to convert my code from using the regular Java JDK file api to the VFS api, and I found that in a number of places, I now have to add a try/catch block to handle a checked exception where I previously didn't have to (e.g. File.listFiles() vs. FileObject.getChildren(), new File(myFile) vs. VFS.getManager().resolveFile(myFile)) Having one less impediment to migrate would make it easier to adopt for more people. As a frame of reference, Hibernate did make a change like this to convert HibernateException from checked to runtime, and it was fine for them _Patch and Impact of Change_ I've attached a patch of the change - you can see it is very small, and the code still compiles. I ran a test locally and it failed on some of the external-resource-related bits; I can follow up on this, but would like to first get your approval on this ticket before proceeding w/ any more work In terms of client changes - this would only impact clients that happened to explicitly expect an IOException in their catch block, and not directly the FileSystemException. (this affected one piece of code within VFS itself, but could affect clients). But I believe that this still would be a beneficial change, as it would make all clients' code cleaner and make it easier to adopt -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-819) EnumUtils.generateBitVector needs a ? extends
[
https://issues.apache.org/jira/browse/LANG-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862742#comment-13862742
]
Shevek commented on LANG-819:
-
You misunderstand type bounds. Anyway, here is an example.
public class EnumTest {
enum Foo {
A, B, C;
}
public static void main(String[] args) {
Set? extends Foo set = EnumSet.allOf(Foo.class);
// set.add(Foo.B); // Fails to compile: Set is typed read-only. See
references above.
EnumUtils.generateBitVector(Foo.class, set);// Also fails to
compile, even though legitimate.
generateBitVector(Foo.class, set); // Compiles fine, as method has
correct type.
}
// Note method signature now has correct type for a method which only reads
from the given set.
public static E extends EnumE long generateBitVector(ClassE
enumClass, Iterable? extends E values) {
long total = 0;
for (E constant : values)
total |= 1 constant.ordinal();
return total;
}
}
EnumUtils.generateBitVector needs a ? extends
---
Key: LANG-819
URL: https://issues.apache.org/jira/browse/LANG-819
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Reporter: Shevek
Priority: Minor
public static E extends EnumE long generateBitVector(ClassE
enumClass, IterableE values) {
Should be Iterable? extends E.
This is because although no subclasses of E can exist, the ? extends is a
common idiom for marking the collection as readonly, or not owned by the
current object.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (VFS-509) Can't add a FileSystem using the API
[ https://issues.apache.org/jira/browse/VFS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862745#comment-13862745 ] Shevek commented on VFS-509: Withdraw bug, using addProvider(). Can't add a FileSystem using the API Key: VFS-509 URL: https://issues.apache.org/jira/browse/VFS-509 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Shevek I can't take a StandardFileSystemManager and add a FileSystemProvider using the Java APIs. Well, I can, but I have to use reflection. A FileSystem requires a VfsComponentContext. This is not accessible using public APIs on the FSM or any VfsComponent. Although it has no state, the class is protected, so I can't instantiate one either. Please make enough of the API public that this simple task can be performed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (VFS-509) Can't add a FileSystem using the API
[ https://issues.apache.org/jira/browse/VFS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shevek closed VFS-509. -- Resolution: Invalid Can't add a FileSystem using the API Key: VFS-509 URL: https://issues.apache.org/jira/browse/VFS-509 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Shevek I can't take a StandardFileSystemManager and add a FileSystemProvider using the Java APIs. Well, I can, but I have to use reflection. A FileSystem requires a VfsComponentContext. This is not accessible using public APIs on the FSM or any VfsComponent. Although it has no state, the class is protected, so I can't instantiate one either. Please make enough of the API public that this simple task can be performed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862752#comment-13862752 ] Shant Stepanian commented on VFS-508: - I would say then whether something is recoverable depends on the use case I see your point that for distributed systems and infrastructure software, you would have to deal with this on a regular basis, and such exceptions are recoverable for your use use But my use case is for writing business application software, where our systems focus on solving operational or informational problems for our users. Here, we are not the providers of core infrastructure libraries, but the users. And so our code often would be executed either as 1) a scheduled command-line batch application that starts up periodically, runs, and exists; or 2) within a container, such as JBoss or Tomcat, that already provides the infrastructure around request handling and error processing. So to put example 2) in another way - the Tomcat code itself takes care of the error handling at the lower-levels of the stack (e.g. the network requests, HTTP handling, etc.), whereas our business code takes care of error handling at higher levels (e.g. missing business data, validation of user inputs on a UI) In terms of VFS - I would typically be able to delegate to the container that runs my code to handle lower-level failures of the file system requests. I would like to use VFS in our business apps as it does provide a useful abstraction over the file system. We often need to read file-like information from various sources (whether the raw file system, the classpath, FTP, HTTP, ...) and it would be useful to have a uniform way of accessing this data. (After all, in Enterprise IT, the big problems we are trying to solve is just how to gather information from different places and make sense of it for our users). So we would not need to or want to deal with exception handling at the level that you are for your systems. I think the level of exception handling that you do for your system is appropriate as you are writing the important core code for networking systems, whereas my code is leveraging the core infrastructure of others to write business logic without having to dive into the infrastructure code itself I do not know what other types of users currently use VFS (whether infra- or business- facing systems), but I would say that from an Enterprise IT / business IT perspective, the VFS API would be much more useful to us if these were not all checked exceptions and we were not forced to have to handle these, as the containers in which we write our code (whether simple command-line apps or J2EE) already handle it for us. And I'd say that declaring the throws block as a runtimeexception would be able to work best for all sides (infra-style code can still see the kinds of exceptions that may be thrown and handle them, whereas business IT apps would not need to deal with these for most instances) If you have additional q's on my use case, let me know Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached) --- Key: VFS-508 URL: https://issues.apache.org/jira/browse/VFS-508 Project: Commons VFS Issue Type: Improvement Reporter: Shant Stepanian Attachments: changeFileSystemToRuntime.patch I'd like to see if we can FileSystemException to inherit from a RuntimeException, and not IOException I searched the JIRA and didn't see any old tickets referring to this, so I'll bring it up here _The reason_ The reason would go back to the whole Runtime vs. Checked exception debate, and I do prefer the RuntimeException argument that with those, you have the choice on whether to declare the try/catch block upon usage, whereas Checked exceptions force that on you In particular, I bring this up because I feel it hurts the usability of the API to have all operations as a checked exception. I recently looked to convert my code from using the regular Java JDK file api to the VFS api, and I found that in a number of places, I now have to add a try/catch block to handle a checked exception where I previously didn't have to (e.g. File.listFiles() vs. FileObject.getChildren(), new File(myFile) vs. VFS.getManager().resolveFile(myFile)) Having one less impediment to migrate would make it easier to adopt for more people. As a frame of reference, Hibernate did make a change like this to convert HibernateException from checked to runtime, and it was fine for them _Patch and Impact of Change_ I've attached a patch of the change - you can see it is very small, and the code still compiles. I ran a test locally and it failed on some of the
[jira] [Commented] (VFS-508) Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached)
[ https://issues.apache.org/jira/browse/VFS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862764#comment-13862764 ] Shevek commented on VFS-508: And if the container detects an error, how is it to report it to your application? Are you just looking for an exception which passes from the container filesystem routine through your code to the container top level handler? If it throws an unspecified runtime, then when you DO want to do cleanup, you either have to catch RuntimeException (which I HOPE we all agree is bad) or ...? If you're a commandline app, and you don't care, declare main() to throw Exception. If you're in J2EE, then use Throwables.propagate(). If you really don't care about exceptions (or types), use Groovy. In any case, this is a bad patch, as better solutions are available to you. Change FileSystemException to inherit from a RuntimeException, and not IOException (patch attached) --- Key: VFS-508 URL: https://issues.apache.org/jira/browse/VFS-508 Project: Commons VFS Issue Type: Improvement Reporter: Shant Stepanian Attachments: changeFileSystemToRuntime.patch I'd like to see if we can FileSystemException to inherit from a RuntimeException, and not IOException I searched the JIRA and didn't see any old tickets referring to this, so I'll bring it up here _The reason_ The reason would go back to the whole Runtime vs. Checked exception debate, and I do prefer the RuntimeException argument that with those, you have the choice on whether to declare the try/catch block upon usage, whereas Checked exceptions force that on you In particular, I bring this up because I feel it hurts the usability of the API to have all operations as a checked exception. I recently looked to convert my code from using the regular Java JDK file api to the VFS api, and I found that in a number of places, I now have to add a try/catch block to handle a checked exception where I previously didn't have to (e.g. File.listFiles() vs. FileObject.getChildren(), new File(myFile) vs. VFS.getManager().resolveFile(myFile)) Having one less impediment to migrate would make it easier to adopt for more people. As a frame of reference, Hibernate did make a change like this to convert HibernateException from checked to runtime, and it was fine for them _Patch and Impact of Change_ I've attached a patch of the change - you can see it is very small, and the code still compiles. I ran a test locally and it failed on some of the external-resource-related bits; I can follow up on this, but would like to first get your approval on this ticket before proceeding w/ any more work In terms of client changes - this would only impact clients that happened to explicitly expect an IOException in their catch block, and not directly the FileSystemException. (this affected one piece of code within VFS itself, but could affect clients). But I believe that this still would be a beneficial change, as it would make all clients' code cleaner and make it easier to adopt -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (LANG-819) EnumUtils.generateBitVector needs a ? extends
[
https://issues.apache.org/jira/browse/LANG-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862772#comment-13862772
]
Matt Benson commented on LANG-819:
--
What have I said to lead you to conclude that I misunderstand type bounds? It
almost seems (and I hope I'm wrong) that I understand them in such a
fundamental way that I cannot be easily talked into doing something that makes
_perfect_ sense in the general case, but feels totally useless in this specific
one.
Your example is all well and good _for non-{{final}} types_, but {{Set?
extends Foo}} is IMHO a red herring. {{EnumSet.allOf(Foo.class)}} returns
{{EnumSetFoo}}, _not_ {{EnumSet? extends Foo}}; therefore the entire
example is contrived. If for some reason you were using a {{Set}} of whatever
element type that you didn't already _know_ was {{enum}} you'd never _pass_
that {{Set}} to {{EnumUtils#generateBitVector()}} without first somehow
checking that, at which point you'd have to cast the {{Set}} anyway to call the
bit vector method.
I comprehend that you are saying the {{? extends E}} idiom makes the compiler
disallow the modification of a {{Collection}} (an {{Iterable}} can't be
modified without casting to {{Collection}} anyway) and I can make the logical
leap that _because of this_ it may be a visual shorthand for read-only, yet I
_still_ stubbornly refuse to be bullied by this fact when you have not:
* explained your (lacking clarification, striking me as rude and condescending)
assertion that I misunderstand type bounds
* provided a realistic example of code that suffers because of the current
parameter specification
* explained how [this
comment|https://issues.apache.org/jira/browse/LANG-819?focusedCommentId=13452659page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13452659]
is germane to the discussion
Regards,
Matt
EnumUtils.generateBitVector needs a ? extends
---
Key: LANG-819
URL: https://issues.apache.org/jira/browse/LANG-819
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0.1
Reporter: Shevek
Priority: Minor
public static E extends EnumE long generateBitVector(ClassE
enumClass, IterableE values) {
Should be Iterable? extends E.
This is because although no subclasses of E can exist, the ? extends is a
common idiom for marking the collection as readonly, or not owned by the
current object.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
