Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Date: Thu, 24 Oct 2013 10:25:01 +0000 (UTC)
From: "Guillaume Chauvet (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Message-ID: <JIRA.12674118.1381928708454.962.1382610301322@arcas>
In-Reply-To: <JIRA.12674118.1381928708454@arcas>
References: <JIRA.12674118.1381928708454@arcas>
Subject: [jira] [Commented] (OPENJPA-2439) Improving compliance to Java 5+
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OPENJPA-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804036#comment-13804036 ] 

Guillaume Chauvet commented on OPENJPA-2439:
--------------------------------------------

> My only(paranoid) concern with this patch is the part where we replace references to NestableRuntimeException with
> RuntimeException.

Of course this means that the user must update his source code for this specific use case...

> Is it possible that a user currently has code that catchs a RuntimeException, then casts it to  NestableRuntimeException to get the exception details? ... and if so, this change is going to break that code.

... but since Java 1.4, the "cause" exception is accessible from RuntimeException; In other words, casting to NestableRuntimeException is unnecessary :)
In addition, JPA implementations are not expected to influance the client side code; the use of RuntimeException provided by  the JRE appears more appropriate now. Deleting this reference also will participate to reduce coupling between artefacts.

Anyway, this kind of change shall be clearly indicated in the release note, if accepted.


> I guess I don't follow the necessity of adding @Override annotations... what is the benefit of such a change?

In my mind, there are two benefits :
1) Take advantage of the compiler checking to make sure you actually are overriding the wanted method.
2) Makes the code easier to understand because it is more obvious when methods are overwritten.

> Improving compliance to Java 5+
> -------------------------------
>
>                 Key: OPENJPA-2439
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2439
>             Project: OpenJPA
>          Issue Type: Dependency upgrade
>    Affects Versions: 2.3.0
>            Reporter: Guillaume Chauvet
>         Attachments: OPENJPA-2439_final.patch, OPENJPA-2439.patch
>
>
> Hello,
> I provide this patch to improve the compliant of OpenJPA to Java 5+.
> Changes included in this patch are :
> ======
> # Migrating from commons-lang to commons-lang3 :
> Implies :
> -> Removing call to NestedExceptions classes.Explanation from commons-lang homepage :
> "In Java 1.4, the notion that all Throwables could be linked to a cause was introduced. In Lang we had provided a NestedException framework to support the same feature, and now that we're jumping from Java 1.3 to Java 5 we are remove this feature. The deprecation section below covers one part of ExceptionUtils that remains until we are on Java 6, where the last remaining parts of the JDK appear to have embraced the new cause API."
> -> Replace package **.apache.commons.lang to **.apache.commons.lang3
> # Migrating SLF4J artefact to 1.7.5 :
> According to SLF4J news (http://www.slf4j.org/news.html) :
> - Given the significance of these performance improvements, users are highly encouraged to migrate to SLF4J version 1.7.5 or later.
> # Migrating artefact org.apache.bval.bundle form version 0.3-incubating to 0.5 (removing direct SLF4J 1.6.1 and commons-lang2 dependencies)
> If this patch is approved, I will create a subtask for adding @Override annotation to all java classes (maven-compiler plugin is configured to target bytecode version 1.6).


--
This message was sent by Atlassian JIRA
(v6.1#6144)