I think most of these (and other) problems associated with JavaEE
would go away if it would adopt the Jetty model: Don't deploy your
application in Jetty, deploy Jetty in your application.
I can't begin to explain how many problems went away as soon as I
made the switch. This is
Hi,
JDK7 triggers a compiler error on non-final methods annotated with
@SafeVarargs even if the class itself is final. I couldn't find any
literature indicating whether this is intentional (the Javadoc states
that the method must be final but says nothing about final classes). Can
we
On 10/10/2013 3:22 AM, cowwoc wrote:
Hi,
JDK7 triggers a compiler error on non-final methods annotated with
@SafeVarargs even if the class itself is final. I couldn't find any
literature indicating whether this is intentional (the Javadoc states
that the method must be final but says
in the native VM implementation (i.e. libjvm.so) and not to debug
symbols in the java classes in rt.jar.
Regards,
Volker
On Mon, Oct 7, 2013 at 7:45 PM, cowwoc cow...@bbs.darktech.org
mailto:cow...@bbs.darktech.org wrote:
On 07/10/2013 1:35 PM, Steven Schlansker wrote:
On Oct 7, 2013
Subject:Re: Debug builds
Date: Tue, 08 Oct 2013 21:09:11 +0400
From: Alex Kasko alex.kasko.li...@gmail.com
To: cowwoc cow...@bbs.darktech.org
Hi,
I wrote email to the list but decided to send it to you offlist instead
(because it's your thread about debug).Feel free
On 08/10/2013 3:25 PM, Dalibor Topic wrote:
On 10/8/13 8:52 PM, cowwoc wrote:
Dalibor,
I don't think anyone from Oracle reads those forums or has the authority
to make this change. Isn't there a better way for me to bring this up?
Well, you could file a bug report instead, if you
Hi,
Where did the old debug builds of rt.jar go (meaning, rt.jar with
full debug symbols, even for local variables)? I scanned the mailing
list for a related discussion but couldn't find anything. It looks like
somewhere down the line a decision was made to remove these builds, but
it's
On 07/10/2013 1:35 PM, Steven Schlansker wrote:
On Oct 7, 2013, at 8:30 AM, cowwoc cow...@bbs.darktech.org wrote:
Hi,
Where did the old debug builds of rt.jar go (meaning, rt.jar with full
debug symbols, even for local variables)? I scanned the mailing list for a
related discussion
Hi,
Out of curiosity, is JDK 8's type reification improved enough so
that we can replace
E extends EnumE EnumSetE EnumSet.noneOf(ClassE)
with
E extends EnumE EnumSetE EnumSet.noneOf()
and the JDK will figure out the value of E based on the expected
return type? If so, can we
On 01/10/2013 9:40 AM, Alan Bateman wrote:
On 01/10/2013 01:50, Jörn Huxhorn wrote:
…just saying…
We know. It seems unlikely that there will be agreement on a standard
API or that there is time for a new API to bake. So the safest thing
might be just restore the totally unsupported
I prefer throwing exceptions on unusual conditions (e.g. overflow)
and letting the user clamp the value if they so wish. Clamping will lead
to unexpected behavior once values fall outside this range. Yes, it will
be documented, but I daresay most applications won't ever check for it
and
ArithmeticException} whenthe result is out of the supported range.
On Tue, Oct 1, 2013 at 11:45 PM, cowwoc cow...@bbs.darktech.org wrote:
I prefer throwing exceptions on unusual conditions (e.g. overflow) and
letting the user clamp the value if they so wish. Clamping will lead to
unexpected behavior
Hi,
Has this been any new progress on this thread?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
I'd like to second Jörn concerns that shipping JDK8 (less than a
month to go!) without a fix would be extremely problematic. The
performance
.
Martin
cowwoc wrote:
I noticed that TreeMap (and maybe other classes) require a user to either
pass in a Comparator or ensure that all keys must implement Comparable.
The
TreeMap code then uses a utility method whenever it needs to compare two
keys:
/**
* Compares two keys using
14 matches
Mail list logo
