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 mo
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
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 chan
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 inste
Subject:Re: Debug builds
Date: Tue, 08 Oct 2013 21:09:11 +0400
From: Alex Kasko
To: cowwoc
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 to forward it (or its
parts) to the list if you want
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 <mailto:cow...@bbs.darktech.org>> wrote:
On 07/10/2013 1:35 PM, Steven Schlansker wrote:
On Oct 7, 2013, at 8:30 A
On 07/10/2013 1:35 PM, Steven Schlansker wrote:
On Oct 7, 2013, at 8:30 AM, cowwoc 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 but couldn't find any
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 n
Hi,
Out of curiosity, is JDK 8's type reification improved enough so
that we can replace
> EnumSet EnumSet.noneOf(Class)
with
> EnumSet EnumSet.noneOf()
and the JDK will figure out the value of E based on the expected
return type? If so, can we make this API change?
Thanks,
G
nteger constructors and operations throw {@code
ArithmeticException} whenthe result is out of the supported range.
On Tue, Oct 1, 2013 at 11:45 PM, cowwoc wrote:
I prefer throwing exceptions on unusual conditions (e.g. overflow) and
letting the user clamp the value if they so wish. Clampi
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 p
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 getCallerCl
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 impact
eedom I found the changes
to have no significant improvement. I didn't look at, or compare the
generated assembly code for both versions TreeMap.compare(). Though
that might be kind of interesting.
So, from a performance perspective, it appears this SPEC benchmark shows
no change in performan
ough it only invokes a method while the latter does actual
computation.
3) Why is extra time consumed moving from MyComparator.compare(Object,
Object) to (Integer, Integer)? It looks like Generics is doing something at
runtime which consumes a large amount of cpu.
Gili
Clemens Eisserer wrote:
>
&
; it will decrease performance for TreeMaps using "natural ordering".
>
> Aside: It's probably a good idea for the comparator for
> "natural ordering" to be available via some static method.
>
> Martin
>
>
> cowwoc wrote:
>> I noticed that Tree
My understanding is that this has nothing to do with performance.
Certain classes, such as String, as declared final for security reasons.
In the case of Integer I would suggest using composition. It's not as
nice but it'll work.
Gili
Nick Radov wrote:
Is it still necessary for the cor
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 the correct comparison method for th
I see now that ObjectOutputStream.html#useProtocolVersion() already exists:
http://java.sun.com/javase/6/docs/api/java/io/ObjectOutputStream.html#useProtocolVersion(int)
so the only thing we'd need to do in step 2 is add
ObjectStreamConstants.PROTOCOL_VERSION_3.
--
View this message in context:
Hi,
Bug URL: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4128333
I'd like to start a discussion on how we can possibly solve this bug in a
backwards-compatible way. Here is my personal proposal but I'd love to hear
your own ideas!
1) Add a new method to DataInputStream/DataOutputStream f
20 matches
Mail list logo
