From danarmak at gmail.com  Fri Mar 10 19:40:04 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Fri, 10 Mar 2017 21:40:04 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
Message-ID: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>

Hi,

There are two issues that I?ve encountered.

First, jol assumes any class whose simple name is ?int? is the primitive
int type, etc. But languages other than Java can create classes with such a
simple name, and it?s a valid JVM class name. So this Scala code produces:

class byte
case class Foo(x: byte, y: byte)

println(ClassLayout.parseClass(classOf[Foo2]).toPrintable)

Foo object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0    12        (object header)                           N/A
     12     1   byte Foo.x                                    N/A
     13     3        (alignment/padding gap)
     16     1   byte Foo.y                                    N/A
     17     7        (loss due to the next object alignment)
Instance size: 24 bytes
Space losses: 3 bytes internal + 7 bytes external = 10 bytes total

While this simply crashes:

class long
case class Foo(x: long, y: long)

println(ClassLayout.parseClass(classOf[Foo]).toPrintable)

Exception in thread "main" java.lang.IllegalStateException: Field
Foo.x @12 (long, 8b) is not aligned
    at org.openjdk.jol.info.ClassLayout.checkInvariants(ClassLayout.java:131)
    at org.openjdk.jol.info.ClassLayout.<init>(ClassLayout.java:123)
    at org.openjdk.jol.layouters.CurrentLayouter.layout(CurrentLayouter.java:78)
    at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:70)
    at org.openjdk.jol.info.ClassLayout.parseClass(ClassLayout.java:54)

The other issue I encountered is JDK-8057919
<https://bugs.openjdk.java.net/browse/JDK-8057919>, which was fixed in JDK9
but is present before that. Class.getSimpleName throws an exception for
some classes generated by non-Java compilers, notably by scalac (SI-2034
<https://issues.scala-lang.org/browse/SI-2034>), whose names are valid JVM
class names but not valid Java class names.
------------------------------

How do you think these issues should / will be fixed? I want to use jol (as
a library), so I?ll probably make a locally modified copy to work around
these issues, but these changes likely wouldn?t be the right/general ones
to make to the upstream source.

Thanks,
?
-- 
Daniel Armak

From shade at redhat.com  Fri Mar 10 22:07:33 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 10 Mar 2017 23:07:33 +0100
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
Message-ID: <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>

Hi,

On 03/10/2017 08:40 PM, Daniel Armak wrote:
> There are two issues that I?ve encountered.
> 
> First, jol assumes any class whose simple name is ?int? is the primitive
> int type, etc. But languages other than Java can create classes with such a
> simple name, and it?s a valid JVM class name. So this Scala code produces:
> 
> class byte
> case class Foo(x: byte, y: byte)

Um. The problem for JOL is that it's internals are using stringy FQDN for class
names to avoid retaining/loading them. This allows, e.g. to reason about heap
dumps without having class definitions around. If your generated class has the
same FQDN as the regular Java "byte", you are going to have a bad time. Unsure
how should this one be fixed.


> The other issue I encountered is JDK-8057919
> <https://bugs.openjdk.java.net/browse/JDK-8057919>, which was fixed in JDK9
> but is present before that. Class.getSimpleName throws an exception for
> some classes generated by non-Java compilers, notably by scalac (SI-2034
> <https://issues.scala-lang.org/browse/SI-2034>), whose names are valid JVM
> class names but not valid Java class names.

Again, not sure how this should be worked around in JOL. It seems to me JDK 9
should be able to handle this correctly anyhow.


> How do you think these issues should / will be fixed? I want to use jol (as
> a library), so I?ll probably make a locally modified copy to work around
> these issues, but these changes likely wouldn?t be the right/general ones
> to make to the upstream source.

So, both things you have are interesting and complicated interop issues. If you
have simple solutions for them, please can contribute them! See:
http://openjdk.java.net/contribute/


Thanks,
-Aleksey


From danarmak at gmail.com  Fri Mar 10 22:19:31 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Sat, 11 Mar 2017 00:19:31 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
Message-ID: <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>

Hi,

For the first issue: my classes don't have an FQDN of "int". They just have
a name of "int" inside some package, so an FQDN of e.g. "com.bar.int".
There's no reason to confuse them with the primitive int type. (Although
even a class with an FQDN of "int" in the default package would still be
distinct from the primitive int type.)

And, since jol is using Class.getSimpleName, not Class.getName, it's not
using FQDNs anyway. So it can't use these 'simple names' to identify
classes anyway, since two similarly named classes in two different packages
would be confused. (Not to mention two similarly named classes from
different classloaders...)

I think jol can and should fix the first issue, e.g. by storing whether a
field's type is primitive whereever it needs to later compare the field
type's name to a primitive type.

As for the second issue, which was fixed in JDK9, given that 'simple names'
are not used to identify classes (since they're not FQDNs anyway), they're
only used when printing output for the user. If that is indeed their only
purpose, then one possible workaround is, when getSimpleName throws, to
fallback to some other string - such as the name of the class (as given by
getName) minus the package prefix.

These fixes would be good enough for me; do you think they would be
appropriate for jol?


Daniel Armak

On Sat, Mar 11, 2017 at 12:07 AM, Aleksey Shipilev <shade at redhat.com> wrote:

> Hi,
>
> On 03/10/2017 08:40 PM, Daniel Armak wrote:
> > There are two issues that I?ve encountered.
> >
> > First, jol assumes any class whose simple name is ?int? is the primitive
> > int type, etc. But languages other than Java can create classes with
> such a
> > simple name, and it?s a valid JVM class name. So this Scala code
> produces:
> >
> > class byte
> > case class Foo(x: byte, y: byte)
>
> Um. The problem for JOL is that it's internals are using stringy FQDN for
> class
> names to avoid retaining/loading them. This allows, e.g. to reason about
> heap
> dumps without having class definitions around. If your generated class has
> the
> same FQDN as the regular Java "byte", you are going to have a bad time.
> Unsure
> how should this one be fixed.
>
>
> > The other issue I encountered is JDK-8057919
> > <https://bugs.openjdk.java.net/browse/JDK-8057919>, which was fixed in
> JDK9
> > but is present before that. Class.getSimpleName throws an exception for
> > some classes generated by non-Java compilers, notably by scalac (SI-2034
> > <https://issues.scala-lang.org/browse/SI-2034>), whose names are valid
> JVM
> > class names but not valid Java class names.
>
> Again, not sure how this should be worked around in JOL. It seems to me
> JDK 9
> should be able to handle this correctly anyhow.
>
>
> > How do you think these issues should / will be fixed? I want to use jol
> (as
> > a library), so I?ll probably make a locally modified copy to work around
> > these issues, but these changes likely wouldn?t be the right/general ones
> > to make to the upstream source.
>
> So, both things you have are interesting and complicated interop issues.
> If you
> have simple solutions for them, please can contribute them! See:
> http://openjdk.java.net/contribute/
>
>
> Thanks,
> -Aleksey
>
>

From danarmak at gmail.com  Sat Mar 11 15:11:29 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Sat, 11 Mar 2017 17:11:29 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
Message-ID: <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>

Here's a simpler proposal: what exactly doesn't work if you just change the
three calls to Class.getSimpleName with getName?

As far as I can see, the only thing that's affected is that printed layout
contains longer, less readable names. This is actually useful sometimes if
you have classes with the same name in different packages. Regardless, a
simple algorithm could be used here (e.g. discard everything until the last
'.').

Also, Class.getName is already used to represent array component types
(ClassData.java line 93). What's the difference?

Daniel Armak

On Sat, Mar 11, 2017 at 12:19 AM, Daniel Armak <danarmak at gmail.com> wrote:

> Hi,
>
> For the first issue: my classes don't have an FQDN of "int". They just
> have a name of "int" inside some package, so an FQDN of e.g. "com.bar.int".
> There's no reason to confuse them with the primitive int type. (Although
> even a class with an FQDN of "int" in the default package would still be
> distinct from the primitive int type.)
>
> And, since jol is using Class.getSimpleName, not Class.getName, it's not
> using FQDNs anyway. So it can't use these 'simple names' to identify
> classes anyway, since two similarly named classes in two different packages
> would be confused. (Not to mention two similarly named classes from
> different classloaders...)
>
> I think jol can and should fix the first issue, e.g. by storing whether a
> field's type is primitive whereever it needs to later compare the field
> type's name to a primitive type.
>
> As for the second issue, which was fixed in JDK9, given that 'simple
> names' are not used to identify classes (since they're not FQDNs anyway),
> they're only used when printing output for the user. If that is indeed
> their only purpose, then one possible workaround is, when getSimpleName
> throws, to fallback to some other string - such as the name of the class
> (as given by getName) minus the package prefix.
>
> These fixes would be good enough for me; do you think they would be
> appropriate for jol?
>
>
> Daniel Armak
>
> On Sat, Mar 11, 2017 at 12:07 AM, Aleksey Shipilev <shade at redhat.com>
> wrote:
>
>> Hi,
>>
>> On 03/10/2017 08:40 PM, Daniel Armak wrote:
>> > There are two issues that I?ve encountered.
>> >
>> > First, jol assumes any class whose simple name is ?int? is the primitive
>> > int type, etc. But languages other than Java can create classes with
>> such a
>> > simple name, and it?s a valid JVM class name. So this Scala code
>> produces:
>> >
>> > class byte
>> > case class Foo(x: byte, y: byte)
>>
>> Um. The problem for JOL is that it's internals are using stringy FQDN for
>> class
>> names to avoid retaining/loading them. This allows, e.g. to reason about
>> heap
>> dumps without having class definitions around. If your generated class
>> has the
>> same FQDN as the regular Java "byte", you are going to have a bad time.
>> Unsure
>> how should this one be fixed.
>>
>>
>> > The other issue I encountered is JDK-8057919
>> > <https://bugs.openjdk.java.net/browse/JDK-8057919>, which was fixed in
>> JDK9
>> > but is present before that. Class.getSimpleName throws an exception for
>> > some classes generated by non-Java compilers, notably by scalac (SI-2034
>> > <https://issues.scala-lang.org/browse/SI-2034>), whose names are valid
>> JVM
>> > class names but not valid Java class names.
>>
>> Again, not sure how this should be worked around in JOL. It seems to me
>> JDK 9
>> should be able to handle this correctly anyhow.
>>
>>
>> > How do you think these issues should / will be fixed? I want to use jol
>> (as
>> > a library), so I?ll probably make a locally modified copy to work around
>> > these issues, but these changes likely wouldn?t be the right/general
>> ones
>> > to make to the upstream source.
>>
>> So, both things you have are interesting and complicated interop issues.
>> If you
>> have simple solutions for them, please can contribute them! See:
>> http://openjdk.java.net/contribute/
>>
>>
>> Thanks,
>> -Aleksey
>>
>>
>

From shade at redhat.com  Mon Mar 13 13:58:41 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 13 Mar 2017 14:58:41 +0100
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
Message-ID: <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>

On 03/11/2017 04:11 PM, Daniel Armak wrote:
> Here's a simpler proposal: what exactly doesn't work if you just change the
> three calls to Class.getSimpleName with getName?
> 
> As far as I can see, the only thing that's affected is that printed layout
> contains longer, less readable names. This is actually useful sometimes if you
> have classes with the same name in different packages. Regardless, a simple
> algorithm could be used here (e.g. discard everything until the last '.').
> 
> Also, Class.getName is already used to represent array component types
> (ClassData.java line 93). What's the difference?

Ah, I missed this part. Yes, JOL should indeed use FQDNs. I thought it did!

I don't think we care as much about larger printouts, and if we are, we can
shorten the package prefixes to be enough to disambiguate (e.g. j.u.HashMap
instead of java.util.HashMap).

Please submit the patch?

Thanks,
-Aleksey


From danarmak at gmail.com  Mon Mar 13 18:57:06 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Mon, 13 Mar 2017 20:57:06 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
Message-ID: <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>

The attached patch simply replaces the 3 calls to getSimpleName with
getName. The tests pass successfully. The output of sample #1 now looks
like this:

org.openjdk.jol.samples.JOLSample_01_Basic$A object internals:
 OFFSET  SIZE      TYPE DESCRIPTION                                      VALUE
      0    12           (object header)                                  N/A
     12     1   boolean org.openjdk.jol.samples.JOLSample_01_Basic$A.f   N/A
     13     3           (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 3 bytes external = 3 bytes total

?
Thanks,

-- 
Daniel Armak
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Dont_call_getSimpleName.patch
Type: text/x-patch
Size: 1649 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jol-dev/attachments/20170313/e02238fb/Dont_call_getSimpleName.patch>

From ashipile at redhat.com  Thu Mar 16 12:36:52 2017
From: ashipile at redhat.com (ashipile at redhat.com)
Date: Thu, 16 Mar 2017 12:36:52 +0000
Subject: hg: code-tools/jol: 7901916: JOL misinterprets "foo.int"-type field
 as int field
Message-ID: <201703161236.v2GCaq5V025150@aojmv0008.oracle.com>

Changeset: a3f7d0dc8f8d
Author:    shade
Date:      2017-03-16 13:35 +0100
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/a3f7d0dc8f8d

7901916: JOL misinterprets "foo.int"-type field as int field

! jol-core/src/main/java/org/openjdk/jol/info/ClassData.java
! jol-core/src/main/java/org/openjdk/jol/info/ClassLayout.java
! jol-core/src/main/java/org/openjdk/jol/info/FieldData.java
! jol-core/src/main/java/org/openjdk/jol/info/FieldLayout.java
+ jol-core/src/test/java/org/openjdk/jol/jvms/ByteLongTest.java
+ jol-core/src/test/java/org/openjdk/jol/util/ByteClassLoader.java
! jol-core/src/test/java/org/openjdk/jol/util/ClassGenerator.java


From shade at redhat.com  Thu Mar 16 12:38:07 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 16 Mar 2017 13:38:07 +0100
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
Message-ID: <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>

On 03/13/2017 07:57 PM, Daniel Armak wrote:
> The attached patch simply replaces the 3 calls to getSimpleName with getName.
> The tests pass successfully. The output of sample #1 now looks like this:

I pushed the variant of this, along with tests and output tuneups as:
  https://bugs.openjdk.java.net/browse/CODETOOLS-7901916

Please test, and make corrections if you see problems in your use cases. If no
problems are found, I would promote to Maven Central.

Thanks,
-Aleksey



From danarmak at gmail.com  Thu Mar 16 13:16:53 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Thu, 16 Mar 2017 15:16:53 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
Message-ID: <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>

Thanks! This resolves the issue of confusing a class named "int" with the
primitive type.

Unfortunately, it doesn't resolve the issue of getSimpleName throwing due
to JDK-8057919, because getCanonicalName calls getSimpleName.

Actually, I think getCanonicalName isn't a good idea regardless, because it
returns null for anonymous classes, and I think you should use getName
instead in those cases. So you might as well use getName also if
getCanonicalName throws, or just always use it.

Daniel Armak

On Thu, Mar 16, 2017 at 2:38 PM, Aleksey Shipilev <shade at redhat.com> wrote:

> On 03/13/2017 07:57 PM, Daniel Armak wrote:
> > The attached patch simply replaces the 3 calls to getSimpleName with
> getName.
> > The tests pass successfully. The output of sample #1 now looks like this:
>
> I pushed the variant of this, along with tests and output tuneups as:
>   https://bugs.openjdk.java.net/browse/CODETOOLS-7901916
>
> Please test, and make corrections if you see problems in your use cases.
> If no
> problems are found, I would promote to Maven Central.
>
> Thanks,
> -Aleksey
>
>
>

From ashipile at redhat.com  Fri Mar 17 13:01:30 2017
From: ashipile at redhat.com (ashipile at redhat.com)
Date: Fri, 17 Mar 2017 13:01:30 +0000
Subject: hg: code-tools/jol: 7901918: Work around Class.getSimpleName() bug
Message-ID: <201703171301.v2HD1Utk001246@aojmv0008.oracle.com>

Changeset: eaec6cb58043
Author:    shade
Date:      2017-03-17 14:00 +0100
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/eaec6cb58043

7901918: Work around Class.getSimpleName() bug

! jol-core/src/main/java/org/openjdk/jol/info/ClassData.java
! jol-core/src/main/java/org/openjdk/jol/info/FieldData.java
! jol-core/src/main/java/org/openjdk/jol/util/ClassUtils.java
! jol-core/src/test/java/org/openjdk/jol/jvms/DoubleInnerTest.java < jol-core/src/test/java/org/openjdk/jol/jvms/ByteLongTest.java


From ashipile at redhat.com  Fri Mar 17 13:18:56 2017
From: ashipile at redhat.com (ashipile at redhat.com)
Date: Fri, 17 Mar 2017 13:18:56 +0000
Subject: hg: code-tools/jol: 7901919: Handle classes that do not have
 canonical name properly
Message-ID: <201703171318.v2HDIuGE005497@aojmv0008.oracle.com>

Changeset: 04f22d8a627b
Author:    shade
Date:      2017-03-17 14:12 +0100
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/04f22d8a627b

7901919: Handle classes that do not have canonical name properly

! jol-core/src/main/java/org/openjdk/jol/util/ClassUtils.java
! jol-core/src/test/java/org/openjdk/jol/jvms/AnonymousTest.java < jol-core/src/test/java/org/openjdk/jol/jvms/DoubleInnerTest.java


From shade at redhat.com  Fri Mar 17 13:18:30 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 17 Mar 2017 14:18:30 +0100
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
Message-ID: <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>

On 03/16/2017 02:16 PM, Daniel Armak wrote:
> Thanks! This resolves the issue of confusing a class named "int" with the
> primitive type.
> 
> Unfortunately, it doesn't resolve the issue of getSimpleName throwing due to
> JDK-8057919, because getCanonicalName calls getSimpleName. 
> 
> Actually, I think getCanonicalName isn't a good idea regardless, because it
> returns null for anonymous classes, and I think you should use getName instead
> in those cases. So you might as well use getName also if getCanonicalName
> throws, or just always use it.

The trouble with using getName() is that it replies the JVM signature like C],
which is not very human-readable.

These two fixes should solve the issue from JDK-8057919 and handle anonymous
classes well:
  https://bugs.openjdk.java.net/browse/CODETOOLS-7901918
  https://bugs.openjdk.java.net/browse/CODETOOLS-7901919

Check now, please?

-Aleksey


From danarmak at gmail.com  Sun Mar 19 10:21:56 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Sun, 19 Mar 2017 12:21:56 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
 <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
Message-ID: <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>

Yes, that works! Thank you very much.

-- 
Daniel Armak

From shade at redhat.com  Mon Mar 20 09:43:36 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Mar 2017 10:43:36 +0100
Subject: JOL 0.8
Message-ID: <c3c74430-851c-f5f7-0db1-b3b0a70cf6ba@redhat.com>

Hi,

JOL 0.8 is released and available at Maven Central. It includes the following
bugfixes, mostly targeted on JVM languages:

 *) JOL misinterprets "foo.int" class as primitive:
   https://bugs.openjdk.java.net/browse/CODETOOLS-7901916

 *) Work around the JDK Class.getSimpleName() bug:
   https://bugs.openjdk.java.net/browse/CODETOOLS-7901918
   https://bugs.openjdk.java.net/browse/JDK-8057919

 *) JOL mishandles anonymous classes, crashing when introspecting them:
   https://bugs.openjdk.java.net/browse/CODETOOLS-7901919

Enjoy!
-Aleksey


From ashipile at redhat.com  Mon Mar 20 09:46:15 2017
From: ashipile at redhat.com (ashipile at redhat.com)
Date: Mon, 20 Mar 2017 09:46:15 +0000
Subject: hg: code-tools/jol: 3 new changesets
Message-ID: <201703200946.v2K9kGmg012756@aojmv0008.oracle.com>

Changeset: e4e7c79a5911
Author:    shade
Date:      2017-03-20 10:23 +0100
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/e4e7c79a5911

JOL v0.8.

! jol-cli/pom.xml
! jol-core/pom.xml
! jol-samples/pom.xml
! pom.xml

Changeset: 2db955d05981
Author:    shade
Date:      2017-03-20 10:23 +0100
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/2db955d05981

Added tag 0.8 for changeset e4e7c79a5911

! .hgtags

Changeset: 6396eeca69b6
Author:    shade
Date:      2017-03-20 10:23 +0100
URL:       http://hg.openjdk.java.net/code-tools/jol/rev/6396eeca69b6

Continue in 0.9-SNAPSHOT.

! jol-cli/pom.xml
! jol-core/pom.xml
! jol-samples/pom.xml
! pom.xml


From shade at redhat.com  Mon Mar 20 09:45:56 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Mar 2017 10:45:56 +0100
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
 <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
 <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>
Message-ID: <430b4f4f-1d2f-f145-233c-2f81d244237b@redhat.com>

On 03/19/2017 11:21 AM, Daniel Armak wrote:
> Yes, that works! Thank you very much.

Available in JOL 0.8.

-Aleksey


From danarmak at gmail.com  Mon Mar 20 10:20:22 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Mon, 20 Mar 2017 12:20:22 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <430b4f4f-1d2f-f145-233c-2f81d244237b@redhat.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
 <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
 <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>
 <430b4f4f-1d2f-f145-233c-2f81d244237b@redhat.com>
Message-ID: <CADtYB+=_-HmziKJV6BJBL4ABvRmkTAJHdNDg90A5xQLwyN_aPA@mail.gmail.com>

Great! Thank you.

Daniel Armak

On Mon, Mar 20, 2017 at 11:45 AM, Aleksey Shipilev <shade at redhat.com> wrote:

> On 03/19/2017 11:21 AM, Daniel Armak wrote:
> > Yes, that works! Thank you very much.
>
> Available in JOL 0.8.
>
> -Aleksey
>
>

From danarmak at gmail.com  Mon Mar 20 10:27:27 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Mon, 20 Mar 2017 12:27:27 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+=_-HmziKJV6BJBL4ABvRmkTAJHdNDg90A5xQLwyN_aPA@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
 <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
 <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>
 <430b4f4f-1d2f-f145-233c-2f81d244237b@redhat.com>
 <CADtYB+=_-HmziKJV6BJBL4ABvRmkTAJHdNDg90A5xQLwyN_aPA@mail.gmail.com>
Message-ID: <CADtYB+k4sW5rQv_91BKL6aJ+T4i5yzYMnBCFc8r-X3j-OsEE-w@mail.gmail.com>

I don't see 0.8 on Maven Central yet, will it be pushed later?

Daniel Armak

On Mon, Mar 20, 2017 at 12:20 PM, Daniel Armak <danarmak at gmail.com> wrote:

> Great! Thank you.
>
> Daniel Armak
>
> On Mon, Mar 20, 2017 at 11:45 AM, Aleksey Shipilev <shade at redhat.com>
> wrote:
>
>> On 03/19/2017 11:21 AM, Daniel Armak wrote:
>> > Yes, that works! Thank you very much.
>>
>> Available in JOL 0.8.
>>
>> -Aleksey
>>
>>
>

From shade at redhat.com  Mon Mar 20 10:28:50 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Mar 2017 11:28:50 +0100
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+k4sW5rQv_91BKL6aJ+T4i5yzYMnBCFc8r-X3j-OsEE-w@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
 <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
 <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>
 <430b4f4f-1d2f-f145-233c-2f81d244237b@redhat.com>
 <CADtYB+=_-HmziKJV6BJBL4ABvRmkTAJHdNDg90A5xQLwyN_aPA@mail.gmail.com>
 <CADtYB+k4sW5rQv_91BKL6aJ+T4i5yzYMnBCFc8r-X3j-OsEE-w@mail.gmail.com>
Message-ID: <9e6bc89e-b62f-9b9e-91b1-9368e8a9cbb6@redhat.com>

I checked this before:

http://central.maven.org/maven2/org/openjdk/jol/jol-cli/0.8/
http://central.maven.org/maven2/org/openjdk/jol/jol-core/0.8/

-Aleksey

On 03/20/2017 11:27 AM, Daniel Armak wrote:
> I don't see 0.8 on Maven Central yet, will it be pushed later?
> 
> Daniel Armak
> 
> On Mon, Mar 20, 2017 at 12:20 PM, Daniel Armak <danarmak at gmail.com
> <mailto:danarmak at gmail.com>> wrote:
> 
>     Great! Thank you.
> 
>     Daniel Armak
> 
>     On Mon, Mar 20, 2017 at 11:45 AM, Aleksey Shipilev <shade at redhat.com
>     <mailto:shade at redhat.com>> wrote:
> 
>         On 03/19/2017 11:21 AM, Daniel Armak wrote:
>         > Yes, that works! Thank you very much.
> 
>         Available in JOL 0.8.
> 
>         -Aleksey
> 
> 
> 


From danarmak at gmail.com  Mon Mar 20 10:30:28 2017
From: danarmak at gmail.com (Daniel Armak)
Date: Mon, 20 Mar 2017 12:30:28 +0200
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <9e6bc89e-b62f-9b9e-91b1-9368e8a9cbb6@redhat.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
 <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
 <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>
 <430b4f4f-1d2f-f145-233c-2f81d244237b@redhat.com>
 <CADtYB+=_-HmziKJV6BJBL4ABvRmkTAJHdNDg90A5xQLwyN_aPA@mail.gmail.com>
 <CADtYB+k4sW5rQv_91BKL6aJ+T4i5yzYMnBCFc8r-X3j-OsEE-w@mail.gmail.com>
 <9e6bc89e-b62f-9b9e-91b1-9368e8a9cbb6@redhat.com>
Message-ID: <CADtYB+mJQxXhG-4bWZYgVx8S6G_+iTrud8ZsNCsneoFENnO0MA@mail.gmail.com>

But this search doesn't find it (yet?):

https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.openjdk.jol%22%20AND%20a%3A%22jol-core%22

Maybe they only update their indexes periodically and not whenever you
upload something.

Daniel Armak

On Mon, Mar 20, 2017 at 12:28 PM, Aleksey Shipilev <shade at redhat.com> wrote:

> I checked this before:
>
> http://central.maven.org/maven2/org/openjdk/jol/jol-cli/0.8/
> http://central.maven.org/maven2/org/openjdk/jol/jol-core/0.8/
>
> -Aleksey
>
> On 03/20/2017 11:27 AM, Daniel Armak wrote:
> > I don't see 0.8 on Maven Central yet, will it be pushed later?
> >
> > Daniel Armak
> >
> > On Mon, Mar 20, 2017 at 12:20 PM, Daniel Armak <danarmak at gmail.com
> > <mailto:danarmak at gmail.com>> wrote:
> >
> >     Great! Thank you.
> >
> >     Daniel Armak
> >
> >     On Mon, Mar 20, 2017 at 11:45 AM, Aleksey Shipilev <shade at redhat.com
> >     <mailto:shade at redhat.com>> wrote:
> >
> >         On 03/19/2017 11:21 AM, Daniel Armak wrote:
> >         > Yes, that works! Thank you very much.
> >
> >         Available in JOL 0.8.
> >
> >         -Aleksey
> >
> >
> >
>
>

From shade at redhat.com  Mon Mar 20 10:31:55 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 20 Mar 2017 11:31:55 +0100
Subject: Class.getSimpleName not suitable for non-Java classes
In-Reply-To: <CADtYB+mJQxXhG-4bWZYgVx8S6G_+iTrud8ZsNCsneoFENnO0MA@mail.gmail.com>
References: <CADtYB+nzKsydj8oY3xpMBXsu0WtB8_X1zqM2y+sn0_muCh+fCw@mail.gmail.com>
 <d9fb0492-ddf0-6280-a995-784d1c386cdd@redhat.com>
 <CADtYB+kKjg9LXhhswxGykZ1SBy_Ho9YrOCqRZLu-BArJpS7phw@mail.gmail.com>
 <CADtYB+k_s+cWkL7_M-FfS0fb6k0_OrnsN5Op3G5v0m7Lt9OatQ@mail.gmail.com>
 <f8c1dc03-1970-da58-4249-32097f05686a@redhat.com>
 <CADtYB+=ViuKtQ18=rZpkBnGMQvzpQUFup9Doarjzh-OSMriyLw@mail.gmail.com>
 <1935a49f-c9cb-806a-8680-87a42a74ec4c@redhat.com>
 <CADtYB+kj09AtBpJACBWCnHFKV5jOHAEpMFzeK5H1jY3dWq1BMw@mail.gmail.com>
 <10d000d1-b902-ee90-ca16-8a26dce89ca8@redhat.com>
 <CADtYB+mWDOF082L4CDabJgKjAEaEPmUKRH-eFdOD4dKprdBCjw@mail.gmail.com>
 <430b4f4f-1d2f-f145-233c-2f81d244237b@redhat.com>
 <CADtYB+=_-HmziKJV6BJBL4ABvRmkTAJHdNDg90A5xQLwyN_aPA@mail.gmail.com>
 <CADtYB+k4sW5rQv_91BKL6aJ+T4i5yzYMnBCFc8r-X3j-OsEE-w@mail.gmail.com>
 <9e6bc89e-b62f-9b9e-91b1-9368e8a9cbb6@redhat.com>
 <CADtYB+mJQxXhG-4bWZYgVx8S6G_+iTrud8ZsNCsneoFENnO0MA@mail.gmail.com>
Message-ID: <240a34b3-d7b0-5d82-a8c3-ae96b8cc3e02@redhat.com>

Yes. But dependency management does not care about those indexes, AFAIU. So if
you have the build dependency, you can just update it to 0.8, and it should be
picked up.

-Aleksey

On 03/20/2017 11:30 AM, Daniel Armak wrote:
> But this search doesn't find it (yet?):
> 
> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.openjdk.jol%22%20AND%20a%3A%22jol-core%22
> 
> Maybe they only update their indexes periodically and not whenever you upload
> something.
> 
> Daniel Armak
> 
> On Mon, Mar 20, 2017 at 12:28 PM, Aleksey Shipilev <shade at redhat.com
> <mailto:shade at redhat.com>> wrote:
> 
>     I checked this before:
> 
>     http://central.maven.org/maven2/org/openjdk/jol/jol-cli/0.8/
>     <http://central.maven.org/maven2/org/openjdk/jol/jol-cli/0.8/>
>     http://central.maven.org/maven2/org/openjdk/jol/jol-core/0.8/
>     <http://central.maven.org/maven2/org/openjdk/jol/jol-core/0.8/>
> 
>     -Aleksey
> 
>     On 03/20/2017 11:27 AM, Daniel Armak wrote:
>     > I don't see 0.8 on Maven Central yet, will it be pushed later?
>     >
>     > Daniel Armak
>     >
>     > On Mon, Mar 20, 2017 at 12:20 PM, Daniel Armak <danarmak at gmail.com <mailto:danarmak at gmail.com>
>     > <mailto:danarmak at gmail.com <mailto:danarmak at gmail.com>>> wrote:
>     >
>     >     Great! Thank you.
>     >
>     >     Daniel Armak
>     >
>     >     On Mon, Mar 20, 2017 at 11:45 AM, Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>
>     >     <mailto:shade at redhat.com <mailto:shade at redhat.com>>> wrote:
>     >
>     >         On 03/19/2017 11:21 AM, Daniel Armak wrote:
>     >         > Yes, that works! Thank you very much.
>     >
>     >         Available in JOL 0.8.
>     >
>     >         -Aleksey
>     >
>     >
>     >
> 
> 


From eolivelli at gmail.com  Fri Mar 24 09:36:46 2017
From: eolivelli at gmail.com (Enrico Olivelli)
Date: Fri, 24 Mar 2017 10:36:46 +0100
Subject: Release JOL with compatible Apache2 Licence
Message-ID: <CACcefgfKaVBWptv+5yWegJGiqtybGbU7QbeJaY6crAr_azP5Fw@mail.gmail.com>

Hi,
I would like to use JOL in my Apache2 Licenced project HerdDB (
https://github.com/diennea/herddb).

Is there any plan to release JOL with a compatible Apache2 License ?

Thank you
JOL is very impressive !

Enrico Olivelli

From shade at redhat.com  Fri Mar 24 10:14:22 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 24 Mar 2017 11:14:22 +0100
Subject: Release JOL with compatible Apache2 Licence
In-Reply-To: <CACcefgfKaVBWptv+5yWegJGiqtybGbU7QbeJaY6crAr_azP5Fw@mail.gmail.com>
References: <CACcefgfKaVBWptv+5yWegJGiqtybGbU7QbeJaY6crAr_azP5Fw@mail.gmail.com>
Message-ID: <a280f387-2144-6a6a-8449-cb80e71b6dc0@redhat.com>

On 03/24/2017 10:36 AM, Enrico Olivelli wrote:
> I would like to use JOL in my Apache2 Licenced project HerdDB (
> https://github.com/diennea/herddb).
> 
> Is there any plan to release JOL with a compatible Apache2 License ?

No.

JOL is the OpenJDK project, and governed by the same license as the rest of
OpenJDK: GPLv2 with Classpath Exception. Consult your software licensing lawyers
to figure out if Classpath Exception is enough for your uses.

-Aleksey