Hi,
New webrev: http://cr.openjdk.java.net/~jfranck/8004698/webrev.01/
- More comments in the code, more javadoc comments, hopefully better flow
for enhanced readability.
- I have also reduced permissions on some methods and made most of the
classes immutable.
cheers
/Joel
On 01/17/2013
On 21.01.2013 20:01, Alan Bateman wrote:
On 18/01/2013 16:40, Alexey Utkin wrote:
The main difference is that after the fix Java becomes the program
that could be certified by MS as Vista comparable.
Java would support the dynamic user profiles and follow the changes
in Windows OS policy
On 1/22/2013 13:48, Alexey Utkin wrote:
One thing on SHGetKnownFolderPath is that you specify KF_FLAG_CREATE
and I'm not sure if that is right because we don't want the JDK
creating the user's directory if it doesn't exist.
That is a corner case. In the latest versions of OS, MS is trying to
Well, I think this might be a good idea in order to preserve the
performance of the former implementation. I'd suggest to introduce a
boolean system property that, when specified, would omit these flags
though, so that if someone happens to rely on this behavior, they could
get it back by
To be clear, there are three options for a shell call:
1. Force folder creation if not exists (KF_FLAG_CREATE)
2. Return existent folder if any (0)
3. Return folder name without verification (KF_FLAG_DONT_VERIFY)
Current implementation is close to the last option (without
On 22/01/2013 12:28, Alexey Utkin wrote:
To be clear, there are three options for a shell call:
1. Force folder creation if not exists (KF_FLAG_CREATE)
2. Return existent folder if any (0)
3. Return folder name without verification (KF_FLAG_DONT_VERIFY)
Current implementation is
Hi Peter,
Thanks for your comments, see inline,
On 01/19/2013 06:11 PM, Peter Levart wrote:
I see, there is a dilema how to cache type annotations. To satisfy
single-annotation-returning methods and repeating annotation logic, a
HashMap would be a logical choice, but it has much bigger
On 22.01.2013 16:52, Alan Bateman wrote:
On 22/01/2013 12:28, Alexey Utkin wrote:
To be clear, there are three options for a shell call:
1. Force folder creation if not exists (KF_FLAG_CREATE)
2. Return existent folder if any (0)
3. Return folder name without verification
Hi Alexey,
The fix looks good from code logic perspective.
I'm only concerned with whether we should use the __try/__except magic,
or would it rather make sense to define:
#define IS_WINVISTA (LOBYTE(LOWORD(::GetVersion())) = 6)
and guard the call to SHGetKnownFolderPath() with this check?
Hi Anthony,
The MS back porting process is not trivial.
[SHGetKnownFolderPath] could be introduced is service pack for earlier OS.
In my opinion that is better to use the function based on fact of
present (here the question is more about
Shell32.dll version, not OS version but they are in
On 22.01.2013 19:58, Alan Bateman wrote:
On 22/01/2013 15:45, Anthony Petrov wrote:
Hi Alexey,
The fix looks good from code logic perspective.
I'm only concerned with whether we should use the __try/__except
magic, or would it rather make sense to define:
#define IS_WINVISTA
Thanks for the clarification. If Alan is OK with that, then I'm fine
with the current fix as well.
--
best regards,
Anthony
On 1/22/2013 19:59, Alexey Utkin wrote:
Hi Anthony,
The MS back porting process is not trivial.
[SHGetKnownFolderPath] could be introduced is service pack for earlier
Changeset: be443002e970
Author:mcimadamore
Date: 2013-01-22 16:23 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be443002e970
8006673: TargetType52 fails because of bad golden file
Summary: Fix golden file in negative test
Reviewed-by: jjg
!
Changeset: b61e5f801f7c
Author:mcimadamore
Date: 2013-01-22 16:39 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b61e5f801f7c
8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack
Summary: Lambda desugaring generates spurious references to 'this'
On 01/22/2013 01:47 PM, Joel Borggrén-Franck wrote:
Hi Peter,
Thanks for your comments, see inline,
On 01/19/2013 06:11 PM, Peter Levart wrote:
I see, there is a dilema how to cache type annotations. To satisfy
single-annotation-returning methods and repeating annotation logic, a
HashMap
Hi,
On Jan 22, 2013, at 6:01 PM, Peter Levart peter.lev...@gmail.com wrote:
On 01/22/2013 01:47 PM, Joel Borggrén-Franck wrote:
Hi Peter,
Thanks for your comments, see inline,
On 01/19/2013 06:11 PM, Peter Levart wrote:
I see, there is a dilema how to cache type annotations. To
On 22/01/2013 16:14, Alexey Utkin wrote:
On 22.01.2013 19:58, Alan Bateman wrote:
On 22/01/2013 15:45, Anthony Petrov wrote:
Hi Alexey,
The fix looks good from code logic perspective.
I'm only concerned with whether we should use the __try/__except
magic, or would it rather make sense to
On 01/22/2013 06:08 PM, Joel Borggrén-Franck wrote:
Hi,
On Jan 22, 2013, at 6:01 PM, Peter Levart peter.lev...@gmail.com wrote:
On 01/22/2013 01:47 PM, Joel Borggrén-Franck wrote:
Hi Peter,
Thanks for your comments, see inline,
On 01/19/2013 06:11 PM, Peter Levart wrote:
I see, there is
Are there any additional comments? I'd like to get this pushed today.
On 01/17/13 16:54, Eric McCorkle wrote:
After (lengthy) examination, it seems that properly addressing the
synthesized parameters issue will require more changes to javac. In
light of this, I think that the synthesized
Hi,
Webrev has been updated to address the build issue in the
new build infra. M
(1) added the java.time packages into common/makefiles.javadoc/CORE_PKGS.gmk
to be included into ct.sym
http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl/
(2) not sure which one should be used for
I've made the changes as suggested by Mike, and this has now been
approved by CCC. Could someone please give it one more look and push it
for me, please?
Thanks,
Jim
http://cr.openjdk.java.net/~jgish/Bug4247235-Add-Blanket-Null-Stmt/
On 22/01/2013 19:09, Xueming Shen wrote:
Hi,
Webrev has been updated to address the build issue in the
new build infra. M
(1) added the java.time packages into
common/makefiles.javadoc/CORE_PKGS.gmk
to be included into ct.sym
http://cr.openjdk.java.net/~sherman/8003680/webrev_ctrl/
(2) not
change set/patch attached for pushing.
Thanks,
Jim
On 01/22/2013 02:40 PM, Jim Gish wrote:
I've made the changes as suggested by Mike, and this has now been
approved by CCC. Could someone please give it one more look and push
it for me, please?
Thanks,
Jim
Hello all;
This is a two piece patch.
8006594: Add jdk_core target to jdk/test/Makefile
8006595: Use jdk/test/Makefile targets in preference to local definitions
I chose to do it as two patches because the changes are in different repos and
the changes in 8006594 could be committed without
Hello all;
This is a patch that has been lingering around in the lambda/lambda repo for a
long time. It adds minimal support for the MacOSX platform to the JDK NetBeans
projects. It could also be used as the basis for similar support for the
langtools NetBeans projects.
The patch also adjust
On 23/01/2013 5:52 AM, Alan Bateman wrote:
On 22/01/2013 19:09, Xueming Shen wrote:
Hi,
Webrev has been updated to address the build issue in the
new build infra. M
(1) added the java.time packages into
common/makefiles.javadoc/CORE_PKGS.gmk
to be included into ct.sym
On 22/01/2013 22:19, David Holmes wrote:
All of the jar building was modified so that jars go into images/lib
not jdk/lib. So it should not be necessary (or desirable) to build
into jdk/lib and then copy over.
Sherman can confirm, but I believe the TzdbZoneRulesProvider requires it
in the lib
On 01/22/2013 02:58 PM, Alan Bateman wrote:
On 22/01/2013 22:19, David Holmes wrote:
All of the jar building was modified so that jars go into images/lib not
jdk/lib. So it should not be necessary (or desirable) to build into jdk/lib and
then copy over.
Sherman can confirm, but I believe the
Changeset: 8ee6d45348ba
Author:vinnie
Date: 2013-01-22 23:32 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ee6d45348ba
6263419: No way to clean the memory for a java.security.Key
Reviewed-by: mullan
! src/share/classes/java/security/PrivateKey.java
!
Am 22.01.2013 21:20, schrieb Vladimir Kozlov:
Thank you, Ulf
I will rename method to encodeISOArray and add comment that it could be
replaced by intrinsic by JVM.
Thanks, that's much better. Thinking about, I would more like encodeArrayToISO or just
encodeToISO_8859_1.
The same arrays
Personally, optimizing for interpreter (or even C1) doesn't seem worth it.
If something's truly hot and best perf is desired then use C2 or tiered.
If the method isn't hot enough to trigger the C2 threshold, then why
bother? You're already behind the 8 ball in terms of performance. Maybe
this is
Slightly unusual situation here. :) We're in the process of staging the
Profiles changes ready for integration to the mainline repos via the
jdk8/build forest. That will happen in a few weeks after a test cycle.
All those changes have already gone out for review etc.
Alan just discovered that
On 23/01/2013 10:14 AM, Vitaly Davidovich wrote:
Personally, optimizing for interpreter (or even C1) doesn't seem worth it.
If something's truly hot and best perf is desired then use C2 or tiered.
If the method isn't hot enough to trigger the C2 threshold, then why
bother? You're already behind
Hello Eric,
In Executable,
283 // TODO: This may eventually need to be guarded by security
284 // mechanisms similar to those in Field, Method, etc.
If not done so already, please file a bug to note this item for
follow-up work.
Extra space:
316
317
Changeset: c18f28312c49
Author:smarks
Date: 2013-01-22 18:30 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18f28312c49
8005646: TEST_BUG:
java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves
process running
Reviewed-by: mchung
!
Hi Mandy,
Yes, I still did need a reviewer for this, thanks. Yeah, it was a pain to
debug, but once I figured out the solution it really was fun. Oh, I don't need
this piece anymore, or this piece, or this piece. Delete, delete, delete.
Negative code FTW!
Pushed:
Changeset: 8943b4213f59
Author:jjg
Date: 2013-01-22 18:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8943b4213f59
8006723: sjavac test fails to compile on clean build
Reviewed-by: ksrini
! test/tools/sjavac/SJavac.java
+ test/tools/sjavac/SJavacWrapper.java
Changeset: f5b70712e0d5
Author:jjg
Date: 2013-01-22 19:06 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f5b70712e0d5
8006728: temporarily workaround jtreg problems for doclint tests in othervm
Reviewed-by: jjh
+ test/tools/doclint/html/AAA.java
+
On 01/22/13 20:21, Joe Darcy wrote:
Hello Eric,
In Executable,
283 // TODO: This may eventually need to be guarded by security
284 // mechanisms similar to those in Field, Method, etc.
If not done so already, please file a bug to note this item for
follow-up work.
I
Changeset: 919afffa70b0
Author:sherman
Date: 2013-01-22 20:59 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/919afffa70b0
8003680: JSR 310 Date/Time API
Summary: Integration of JSR310 Date/Time API for M6
Reviewed-by: alanb, naoto, dholmes
Contributed-by:
Changeset: 8209c91b751d
Author:sherman
Date: 2013-01-22 21:02 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/8209c91b751d
8003680: JSR 310 Date/Time API
Summary: Integration of JSR310 Date/Time API for M6
Reviewed-by: alanb, naoto, dholmes
Contributed-by: scolebou...@joda.org,
41 matches
Mail list logo
