date:20160916

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

2016-09-16 Thread Mandy Chung


> On Sep 16, 2016, at 1:30 PM, Steve Drach  wrote:
> 
>> 
>> VersionHelper.java
>>  nameToVersion can simply be Map (I missed this last round)
> 
> It should be , see line 43 of VersionHelper.

This returns a concatenated string. line 43 will work as is as  (javap shows 
what javac emits.)

> 
>> 
>>  56 String name = cf.getName().replace('/', '.');
>>  57 nameToVersion.put(name, version);
>> 
>> Can you add a check to make sure the version is the same if the entry is 
>> present; otherwise, throw InternalError.  This will catch any unexpected 
>> code path.
> 
> That’s a good idea, but is InternalError the right one?  The spec is a bit 
> ambiguous but implies to me that it’s a JVM error since it’s a subclass of 
> VirtualMachineError.  How about just using the MultiReleaseException?

MultiReleaseException or InternalError is fine too. Right now jdeps will only 
parse a MRJAR of a given version.  I expect that we won’t run into this 
conflict but we may have missed other scenarios.

Mandy

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

2016-09-16 Thread Steve Drach

> This looks good.  Thanks for the update.
> 
> Minor comments below and you can make the change before you push (no need for 
> a new webrev).
> 
> MultiReleaseException.java 
>key and msg should be final fields

Done.

> 
> VersionHelper.java
>   nameToVersion can simply be Map (I missed this last round)

It should be , see line 43 of VersionHelper.

> 
>   63 public static void add(JarFile jarfile, JarEntry e, ClassFile cf) 
> throws ConstantPoolException {
> 
> - can you break “throws …” to the next line.

Done

> 
>   56 String name = cf.getName().replace('/', '.');
>   57 nameToVersion.put(name, version);
> 
> Can you add a check to make sure the version is the same if the entry is 
> present; otherwise, throw InternalError.  This will catch any unexpected code 
> path.

That’s a good idea, but is InternalError the right one?  The spec is a bit 
ambiguous but implies to me that it’s a JVM error since it’s a subclass of 
VirtualMachineError.  How about just using the MultiReleaseException?

> 
> Mandy

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

2016-09-16 Thread Mandy Chung

> On Sep 16, 2016, at 11:40 AM, Steve Drach  wrote:
> 
> A relatively minor update.  I simplified VersionHelper.  No other changes.
> 
> http://cr.openjdk.java.net/~sdrach/8153654/webrev.12/ 
> 

This looks good.  Thanks for the update.

Minor comments below and you can make the change before you push (no need for a 
new webrev).

MultiReleaseException.java 
   key and msg should be final fields

VersionHelper.java
  nameToVersion can simply be Map (I missed this last round)

  63 public static void add(JarFile jarfile, JarEntry e, ClassFile cf) 
throws ConstantPoolException {

- can you break “throws …” to the next line.

  56 String name = cf.getName().replace('/', '.');
  57 nameToVersion.put(name, version);

Can you add a check to make sure the version is the same if the entry is 
present; otherwise, throw InternalError.  This will catch any unexpected code 
path.

Mandy

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

2016-09-16 Thread Steve Drach

A relatively minor update.  I simplified VersionHelper.  No other changes.

http://cr.openjdk.java.net/~sdrach/8153654/webrev.12/ 



> On Sep 14, 2016, at 4:06 PM, Steve Drach  wrote:
> 
> The most recent webrev is 
> http://cr.openjdk.java.net/~sdrach/8153654/webrev.11/ 
> 
> 
> Comments inline
> 
>>> The latest web revs.  Answers to questions in-line below:
>>> 
>>> http://cr.openjdk.java.net/~sdrach/8153654/webrev.10/
>>> 
>>> http://cr.openjdk.java.net/~sdrach/8153654/webrev.jdk/
>> 
>> This looks pretty good. My main comment is in VersionHelper (see below).
>> 
>> ClassFileReader.java
>> 
>> 337 String[] msg = {"err.multirelease.option.exists", 
>> f.getName()};
>> 389 String[] msg = 
>> {"err.multirelease.jar.malformed”,
>> 390 jarfile.getName(), rn
>> 391 };
>> 
>> `msg` is not used.  These lines can be removed.
> 
> Done
> 
>> 
>> line 81-95: this wants to add to VersionHelper if it’s a versioned entry.  I 
>> suggest to move this to VersionHelper, something like this and replace the 
>> add method.
> 
> I did essentially the same thing, but not exactly the same.
> 
>> 
>> public static void addIfVersionedEntry(Path jarfile, String realEntryName, 
>> String className) {
>>   if (realEntryName.startsWith(META_INF_VERSIONS)) {
>>   int len = META_INF_VERSIONS.length();
>>   int n = realEntryName.indexOf('/', len);
>>   if (n > 0) {
>>   String version = realEntryName.substring(len, n);
>>   assert (Integer.parseInt(version) > 8);
>> 
>>   String v = versionMap.get(className);
>>   if (v != null && !v.equals(version)) {
>>   // name associated with a different ClassFile
>>   throw new 
>> MultiReleaseException("err.multirelease.version.associated", className,
>>   v, version);
>>   }
>>   versionMap.put(className, version);
>>   } else {
>>   throw new MultiReleaseException("err.multirelease.jar.malformed",
>>   jarfile.toString(), realEntryName);
>>   }
>>   }
>> }
>> 
>> I prefer to call String::length rather than hardcoding the length.
> 
> OK
> 
>> I don’t see why VersionHelper caches ClassFile.  
> 
> A JarEntry (base) name has a one to many relationship with versions.  This 
> implies the class name also has a one to many relationship with versions.  
> But a ClassFile (derived from the contents of the JarEntry) has a one to one 
> relationship with version.  We desire a one to one
> relationship for className to version and one way to assure that is to create 
> two maps as I now have done.  I think the code is more obvious  now, at least 
> I hope it is.
> 
>> I think it can cache a map from class name to the version for now.  We may 
>> have to handle duplicated classes in more than one modular jar (it’s not 
>> exported and should be allowed).  We could file a separate issue to look 
>> into later.
>> 
>> This needs a CCC for the new --multi-release option.
> 
> That’s next.
> 
>> 
>> Mandy
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

2016-09-16 Thread Chris Bensen

I assume libjvm.so has access to dlopen and dlsym? Can the AIX implementation 
of dladdr live in libjli.so and libjvm.so load it from there?

Chris


> On Sep 16, 2016, at 10:34 AM, Volker Simonis  wrote:
> 
> Hi Christoph,
> 
> I think your change is fine as a quick-fix to fix the build. But
> you're completely right that this should be reworked in the long term.
> I hate to see that we now have the third version of these routines in
> the OpenJDK. Unfortunately a clean solution is not trivial.
> 
> libjli is not linked against libjvm because libjli is actually used to
> load libjvm. So we can not put the dladdr routines for AIX there. But
> I think we should at least consolidate the two versions which will be
> in the class library after your change. Initially I intentionally put
> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
> available to ALL jdk native libraries.
> 
> Unfortunately, with the source code reorganization due to the modular
> changes, the common, top-level aix repository had to go away and the
> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
> With the reorganized, modularized source code layout and build system
> it is not possible to share code between modules. We somehow have to
> fix this although I currently don't know how. IF somebody has an idea,
> please let me know :)
> 
> Regarding your change:
> 
> - can you please move
> 
> +#if defined(_AIX)
> +#include "java_md_aix.h"
> +#endif
> +
> 
> from java_md_common.c to the end of
> java.base/unix/native/libjli/java_md.h. It will then be automatically
> included into java_md_common.c trough java.h which includes java_md.h
> 
> Also, this version of dladdr is inherently not thread safe. I don't
> think that's a problem here, but it would be nice if you could quickly
> check if that's indeed true.
> 
> Besides that, looks good.
> 
> Thanks for fixing,
> Volker
> 
> 
> 
> 
> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>  wrote:
>> Hi,
>> 
>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
>> build as function dladdr is not available on AIX.
>> 
>> There already exist ports of that API in hotspot and awt. With the proposed 
>> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
>> eventually we should think about consolidating and using the hotspot port in 
>> all places by exporting it from libjvm.so for AIX.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>> 
>> Thanks
>> Christoph
>> 
>> 
>>> -Original Message-
>>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On 
>>> Behalf
>>> Of Kumar Srinivasan
>>> Sent: Montag, 12. September 2016 22:57
>>> To: core-libs-dev ; Mandy Chung
>>> ; Chris Bensen 
>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>>> 
>>> Hello,
>>> 
>>> I am sponsoring this changeset for Chris Bensen of the java packager
>>> team, please review  fix for the launcher to  better locate java.home.
>>> 
>>> http://cr.openjdk.java.net/~ksrini/8165524/
>>> 
>>> Thanks
>>> Kumar
>>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

2016-09-16 Thread Volker Simonis

Hi Christoph,

I think your change is fine as a quick-fix to fix the build. But
you're completely right that this should be reworked in the long term.
I hate to see that we now have the third version of these routines in
the OpenJDK. Unfortunately a clean solution is not trivial.

libjli is not linked against libjvm because libjli is actually used to
load libjvm. So we can not put the dladdr routines for AIX there. But
I think we should at least consolidate the two versions which will be
in the class library after your change. Initially I intentionally put
porting_aix.{c,h} into jdk/aix/porting with the intent to make it
available to ALL jdk native libraries.

Unfortunately, with the source code reorganization due to the modular
changes, the common, top-level aix repository had to go away and the
code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
With the reorganized, modularized source code layout and build system
it is not possible to share code between modules. We somehow have to
fix this although I currently don't know how. IF somebody has an idea,
please let me know :)

Regarding your change:

- can you please move

+#if defined(_AIX)
+#include "java_md_aix.h"
+#endif
+

from java_md_common.c to the end of
java.base/unix/native/libjli/java_md.h. It will then be automatically
included into java_md_common.c trough java.h which includes java_md.h

Also, this version of dladdr is inherently not thread safe. I don't
think that's a problem here, but it would be nice if you could quickly
check if that's indeed true.

Besides that, looks good.

Thanks for fixing,
Volker

On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
 wrote:
> Hi,
>
> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
> build as function dladdr is not available on AIX.
>
> There already exist ports of that API in hotspot and awt. With the proposed 
> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
> eventually we should think about consolidating and using the hotspot port in 
> all places by exporting it from libjvm.so for AIX.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>
> Thanks
> Christoph
>
>
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
>> Of Kumar Srinivasan
>> Sent: Montag, 12. September 2016 22:57
>> To: core-libs-dev ; Mandy Chung
>> ; Chris Bensen 
>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>>
>> Hello,
>>
>> I am sponsoring this changeset for Chris Bensen of the java packager
>> team, please review  fix for the launcher to  better locate java.home.
>>
>> http://cr.openjdk.java.net/~ksrini/8165524/
>>
>> Thanks
>> Kumar
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

2016-09-16 Thread Mandy Chung


> On Sep 16, 2016, at 2:58 AM, Langer, Christoph  
> wrote:
> 
> Hi,
> 
> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
> build as function dladdr is not available on AIX.
> 
> There already exist ports of that API in hotspot and awt. With the proposed 
> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
> eventually we should think about consolidating and using the hotspot port in 
> all places by exporting it from libjvm.so for AIX.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/

This looks okay.   It’d be good to consolidate the hotspot and awt code as a 
JVM entry point.  But launcher would need to carry this copy since dladdr is 
called before libjvm.so is loaded.

formatting nit: not align with lines above (4-space indentation)

  55   }
  56   return 0;

Mandy

Re: RFR 9: 8155760 Implement Serialization Filtering

2016-09-16 Thread Brian Goetz

Sorry for being late to this party.

I like the approach, but I have some concerns about the evolvability of this 
API.  The filter already receives a handful of parameters; it seems quite 
unlikely that a use case will not emerge where the filter needs more 
information in the future (say, the caller context, the caller class loader, 
etc.)  One strategy for evolution is, rather than pass a handful of parameters, 
pass an aggregate, where the aggregate has getters for the parameters.  Then 
more getters can be added in the future.  There are other strategies too - but 
I am concerned about being in a migration situation only a few years down the 
road, where there is information that the filter needs.  

> On Sep 8, 2016, at 12:09 PM, Roger Riggs  wrote:
> 
> Please review updates to the Serialization filtering API and implementation:
>  - The ObjectInputFilter pattern based filters support matching on module 
> names as well as package and class names.
>  - Rename of system property and java.security property for configurable 
> filters.  (jdk.serialFilter)
>  - ObjectInputFilter clarifications about the values passed to the filter
>  - Javadoc editorial improvements
>  - Clarification of SerializablePermission description of targets
> 
>  - More tests
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/
> 
> SpecDiff:
> http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html
> 
> Javadoc (subset)
> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream.html
>  
> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter.html
>  
> http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/SerializablePermission.html
> 
> Thanks, Roger
> 
> 
>

Re: OpenJDK JDK-7067885 code changes for community review

2016-09-16 Thread Alexey Ivanov


Hi Alok,

This change should be discussed on swing-dev mailing list because you 
modify behavior of javax.swing.JFileChooser, and on core-libs-dev 
because you also modify java.io.File.


I agree with Alan, using the new API appears to be a better alternative 
than changing java.io.File.



Regards,
Alexey

On 12.09.2016 19:08, Alan Bateman wrote:
Best to follow-up on swing-dev as I assume the right thing is to 
update JFileChooser rather than changing java.io.File to be mutable. 
You did acknowledge near the end of your mail that the new file system 
API supports sym links so it may be that JFileChooser could use that.


-Alan


On 12/09/2016 08:41, Sharma, Alok Kumar (OSTL) wrote:
Following is the fix for JDK-7067885. I am not sure which mailing ID 
to post this.


Bug: FileChooser does not display soft link name if link is to 
nonexistent file/directory

https://bugs.openjdk.java.net/browse/JDK-7067885

This bug is unassigned. Can someone please look into these changes 
and get back to me? Explanation of fix is at the end of the source 
code diff.


Mercurial diff for source change:
---
diff -r 021369229cfd src/java.base/share/classes/java/io/File.java
--- a/src/java.base/share/classes/java/io/File.java Tue Sep 06 
13:09:29 2016 -0400
+++ b/src/java.base/share/classes/java/io/File.java Mon Sep 12 
11:27:07 2016 +0530

@@ -164,6 +164,27 @@
  private final String path;

  /**
+ * The flag indicates whether to follow the symlink.
+ */
+private boolean follow_link = true;
+
+   /**
+* Sets the follow_link of file.
+* description: Sets follow_link on or off.
+* @param follow_link the value that determines whether to follow 
the symlink or not.
+*   TRUE: file.io.exists() checks the file existence using 
stat() which follows the symlink.

+*
+*   FALSE: file.io.exists() checks the file existence using 
lstat() if stat() fails to retrieve
+*  the file info. lstat() if file is a symbolic link, then 
it returns information

+*  about the link itself.
+* @return Returns ZERO at success
+*/
+public int set_follow_link(boolean follow_link) {
+this.follow_link=follow_link;
+return 0;
+}
+
+/**
   * Enum type that indicates the status of a file path.
   */
  private static enum PathStatus { INVALID, CHECKED };
diff -r 021369229cfd 
src/java.base/unix/native/libjava/UnixFileSystem_md.c
--- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Tue Sep 
06 13:09:29 2016 -0400
+++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon Sep 
12 11:27:07 2016 +0530

@@ -51,6 +51,7 @@
#define dirent64 dirent
#define readdir64_r readdir_r
#define stat64 stat
+#define lstat64 lstat
#ifndef MACOSX
#define statvfs64 statvfs
#endif
@@ -62,6 +63,7 @@
  jfieldID path;
} ids;

+jfieldID ufs_follow_link;

JNIEXPORT void JNICALL
Java_java_io_UnixFileSystem_initIDs(JNIEnv *env, jclass cls)
@@ -70,6 +72,8 @@
  if (!fileClass) return;
  ids.path = (*env)->GetFieldID(env, fileClass,
"path", "Ljava/lang/String;");
+ufs_follow_link = (*env)->GetFieldID(env, fileClass,
+  "follow_link", "Z");
}

/* -- Path operations -- */
@@ -113,20 +117,42 @@
  return JNI_FALSE;
}

+static jboolean
+lstatMode(const char *path, int *mode)
+{
+struct stat64 sb;
+if (lstat64(path, ) == 0) {
+*mode = sb.st_mode;
+return JNI_TRUE;
+}
+return JNI_FALSE;
+}

JNIEXPORT jint JNICALL
Java_java_io_UnixFileSystem_getBooleanAttributes0(JNIEnv *env, 
jobject this,

jobject file)
{
  jint rv = 0;
+jint follow_link = 0;

  WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
  int mode;
-if (statMode(path, )) {
-int fmt = mode & S_IFMT;
-rv = (jint) (java_io_FileSystem_BA_EXISTS
-  | ((fmt == S_IFREG) ? 
java_io_FileSystem_BA_REGULAR : 0)
-  | ((fmt == S_IFDIR) ? 
java_io_FileSystem_BA_DIRECTORY : 0));
+follow_link = (*env)->GetBooleanField(env, file, 
ufs_follow_link);

+if ( follow_link ) {
+  if (statMode(path, )) {
+  int fmt = mode & S_IFMT;
+  rv = (jint) (java_io_FileSystem_BA_EXISTS
+| ((fmt == S_IFREG) ? 
java_io_FileSystem_BA_REGULAR : 0)
+| ((fmt == S_IFDIR) ? 
java_io_FileSystem_BA_DIRECTORY : 0));

+  }
+}
+else {
+  if (lstatMode(path, )) {
+  int fmt = mode & S_IFMT;
+  rv = (jint) (java_io_FileSystem_BA_EXISTS
+| ((fmt == S_IFREG) ? 
java_io_FileSystem_BA_REGULAR : 0)
+| ((fmt == S_IFDIR) ? 
java_io_FileSystem_BA_DIRECTORY : 0));

+  }
  }
  } END_PLATFORM_STRING(env, path);
  return rv;
diff -r 021369229cfd

RFR: 8166189: Fix for Bug 8165524 breaks AIX build

2016-09-16 Thread Langer, Christoph

Hi,

the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
build as function dladdr is not available on AIX.

There already exist ports of that API in hotspot and awt. With the proposed 
change I duplicate the awt port to libjli. This is maybe only a quick fix - 
eventually we should think about consolidating and using the hotspot port in 
all places by exporting it from libjvm.so for AIX.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/

Thanks
Christoph


> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
> Of Kumar Srinivasan
> Sent: Montag, 12. September 2016 22:57
> To: core-libs-dev ; Mandy Chung
> ; Chris Bensen 
> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
> 
> Hello,
> 
> I am sponsoring this changeset for Chris Bensen of the java packager
> team, please review  fix for the launcher to  better locate java.home.
> 
> http://cr.openjdk.java.net/~ksrini/8165524/
> 
> Thanks
> Kumar

RFR 8166051: [jline] Cannot parse .inputrc with \r

2016-09-16 Thread Jan Lahoda

Please review a change to how .inputrc is read. Currently, it uses 
BufferedReader.readLine(), which interprets '\r' as a line separator, 
and so the '\r' character cannot be used in the macros. The proposed 
change is to use System.getProperty("line.separator") and "\n" as line 
separators.


Bug:
https://bugs.openjdk.java.net/browse/JDK-8166051

Webrev:
http://cr.openjdk.java.net/~jlahoda/8166051/webrev.00/

Thanks!

Jan

Re: Reg - Sub Process creation from java takes more time

2016-09-16 Thread ecki

Hello,

Does the (virtual) size increase over time when it gets slower? How does the GC 
log looks like, any increasing activity or longer pauses?

If you let this VM run for longer time (when it slows down), will it eventually 
fail because of some resource exhaustion?

How often does the execute work fast, after what numberbof executions and what 
runtime it gets slower?

You can also strace the process to see if the execution time of fork() and 
exec() syscalls increase.

Gruss
Bernd
-- 
http://bernd.eckenfels.net
>From Win 10 Mobile

Von: Manjunath SV

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

Re: RFR: 8153654: Update jdeps to be multi-release jar aware

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Re: RFR 9: 8155760 Implement Serialization Filtering

Re: OpenJDK JDK-7067885 code changes for community review

RFR: 8166189: Fix for Bug 8165524 breaks AIX build

RFR 8166051: [jline] Cannot parse .inputrc with \r

Re: Reg - Sub Process creation from java takes more time

12 matches

Site Navigation

Mail list logo

Footer information