Hi Thiago,
I didn't want to argue with you, just wanted to explain my opinion (and
understand yours). I can accept the decision to stay with private
methods althought I do not agree with you reasons ^^
I'll continue to discuss smaller changes (in behaviour) here.
Kind regards,
Michael.
No, there is no way to access the generic type, this information is lost
during the compilation process.
That's not actually correct. Lets consider the following class:
public class MyClass {
private ListFoo foos;
public ListBar getBars() {
...
}
public void doStuffWithBaz()
Just having a quick poke through the code this could be fixed by adding the
following methods to the public API.
java.lang.reflect.Type PropertyConduit.getPropertyGenericType()
java.lang.reflect.Type Binding.getBindingGenericType()
java.lang.reflect.Type
Thanks Lance, you're correct of course.
Michael, as this is still relevant to you, could you please update the
Affects Version/s: field of your JIRA issue (TAP5-1213) accordingly?
Am 13.05.2014 11:38, schrieb Lance Java:
No, there is no way to access the generic type, this information is
Hi Michel,
Am 12.05.2014 10:58, schrieb Michael Wyraz:
I can access the type of a bound parameter using
ComponentResources.getBoundType(parameterName). But for ListString it
returns (of course) List.class. Is there a way to access the generic
parameters of the bound type somehow?
No, there is
Hi Thiago,
thank you a lot. I changed it to
configuration.add(ImportUIStack, importUIStack,
after:JavaScriptSupport);
This contribution comes from Tapestry's JavaScriptModule. The problem
did not occur in the last hour - I guess it's solved with this change.
Kind Regards,
MIchael.
I have added a comment there concerning the behaviour for literal
bindings. But I dont have permission to change the affected version.
Thanks Lance, you're correct of course.
Michael, as this is still relevant to you, could you please update the
Affects Version/s: field of your JIRA issue
On Tue, 13 May 2014 05:25:22 -0300, Michael Wyraz
michael.wy...@evermind.de wrote:
Hi Thiago,
Hi!
I didn't want to argue with you, just wanted to explain my opinion (and
understand yours). I can accept the decision to stay with private
methods althought I do not agree with you reasons
Any new insights on this one? The current master will still FTBFS on Java 5.
Am 02.05.2014 18:18, schrieb Kalle Korhonen:
On Fri, May 2, 2014 at 12:57 AM, Ulrich Stärk u...@spielviel.de wrote:
I don't see the benefits in this. As I said earlier, Java 6 and 7 IMO
don't provide enough benefits
We could simply take a vote on this - case like this is exactly what the
voting procedures at Apache were originally designed for. We'd need to vote
on a clearly defined issue, like do we want to require Java 6 for T5.4 so
we can upgrade dependencies that require Java 6, such as the newer closure
10 matches
Mail list logo