JDK 13 - Early Access build 14 is available
by Rory O'Donnell
Hi Sanne,
*OpenJDK builds *- JDK 13 - Early Access build 14 is available at
http://jdk.java.net/13/
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B13%22%3A...>
* Release notes [1]
* JDK 13 Schedule proposal accepted [2]
o 2019/06/13 Rampdown Phase One
o 2019/07/18 Rampdown Phase Two
o 2019/08/08 Initial Release Candidate
o 2019/08/22 Final Release Candidate
o 2019/09/17 General Availability
*jpackage EA *
* This is an early access build of JEP 343: Packaging Tool
<https://openjdk.java.net/jeps/343>, aimed at testing a prototype
implementation of jpackage, which is a new tool for packaging
self-contained Java applications along with a Java Runtime Environment.
* Build 30 is now available http://jdk.java.net/jpackage/
* Please send feedback via e-mail to core-libs-dev(a)openjdk.java.net
<mailto:core-libs-dev@openjdk.java.net>
*Quality Outreach report for **March 2019*
* The report for March 2019 is available here
<https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Mar...>
* Thanks to all those contributed !
*Recent Blog:* A new (Japanese) era for Java!
<https://blogs.oracle.com/java-platform-group/a-new-japanese-era-for-java>
Rgds,Rory
[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002736.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
5 years, 7 months
Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing
by Scott Marlow
Hi Tomek,
I think the pending question now is why ByteBuddy is getting a null
result from the
classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
call.
We have also seen failures for
org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which is
also generated by the EJB container (see exception call stack in
https://issues.jboss.org/browse/WFLY-11891).
I wonder if this could be an ordering bug where classes generated via
JBoss ClassFileWriter are added to the classloader list of classes,
before the actual bytecode is added.
Scott
On 3/26/19 9:17 AM, Tomasz Adamski wrote:
> Hi Scott,
>
> Added to my TODO. WIll try to look at it this week.
>
> Regards,
> Tomek
>
> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
> Adding Tomek + Cheng, as they have been working on the WildFly EJB
> layer
> recently, which seems to use
> https://github.com/jbossas/jboss-classfilewriter for generating the EJB
> stub classes like
> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
>
> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
> ByteBuddy should change to handle dynamically generated classes
> differently.
>
> In other words, should ByteBuddy respond differently to
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>
> returning null or should the jboss-classfilewriter project somehow
> avoid
> this bug.
>
> Scott
>
> On 3/22/19 2:54 AM, Gail Badner wrote:
> > Scott added bytecode enhancement to some WildFly tests for
> WFLY-11891 [1],
> > which are failing.
> >
> > Here is Scott's PR with the updated tests: [2]
> >
> > When I stepped into
> >
> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
> > I can see that they are failing in ByteBuddy code.
> >
> > I see that:
> >
> > - enhancement of
> >
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets
> > skipped several times in a row;
> > - enhancement of some other classes get skipped;
> > - before trying to enhance
> >
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an
> > exception is thrown.
> >
> > Unfortunately, I'm having trouble getting a good stacktrace to
> show what
> > happens in ByteBuddy code.
> >
> > Here is what I'm seeing:
> >
> >
> net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
> > /* class name differs from run to run */
> >
> >
> > calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( "
> >
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
> >
> > calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate(
> > classLoader,
> "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5"
> > )
> >
> > calls
> >
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"),
> > which returns null;
> >
> > (I don't actually see a class file with this name)
> >
> >
> > returns new TypePool.Resolution.Illegal(
> >
> >
> "org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"
> >
> > )
> >
> > returns TypePool.Resolution.Illegal
> >
> >
> > Ultimately, TypePool.Resolution.Illegal#resolve( ) throws
> > IllegalStateException, because the type description cannot be
> resolved.
> >
> > I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy.
> >
> > To build WildFly:
> > ./build.sh clean install -DskipTests=true
> >
> > To run the test:
> > cd testsuite/integration/basic
> > mvn install
> >
> -Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase
> >
> > Help would be very much appreciated.
> >
> > Thanks,
> > Gail
> >
> > [1] https://issues.jboss.org/browse/WFLY-11891
> > [2] https://github.com/wildfly/wildfly/pull/12180
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
>
> --
> Regards,
> Tomek
5 years, 7 months
6.0 - multi-table mutations
by Steve Ebersole
While working on 6 I discovered that we maybe do not do the best job in
regards to "bulk update/delete" queries against multi-table entities
(secondary tables, joined inheritance, etc). This short-coming exists in
previous versions. Essentially, when a strategy is not explicitly
specified we fallback to using an "id table" and performing the SQL updates
or deletes using the id table as a sub-query. The problem is that for some
databases this breaks when the ids are composite due to the database not
having complete support for tuples. For example, H2 does not allow the
sub-query for an in-predicate to return more than one column: so a query
like `... where (id1, id2) in (select val1, val2 from ...)` will not work.
This tuple concern is something I had not considered when I first wrote
this feature.
Obviously with 6 we have a chance to improve this. So I have been thinking
about some ways this might be improved. The guiding principle here was to
make this as implicit as possible...
Because certain strategies will not work when the ids are composite, I
think the first consideration is whether we want to allow the strategy to
be definable per-entity. The idea would be to allow for the most efficient
strategy to be used generally (whatever that might be for the given
app/database) but to pick an alternative strategy in cases where that
"fallback" one will not work. The Dialect should certainly play a part in
this strategy selection.
And lastly, we should consider whether it is beneficial to leverage these
strategies when performing normal mutations (merge, persist, etc). I think
really this comes down to whether we think there is a benefit to handling
these via CTE if the database supports that as opposed to sending
individual updates or deletes against each table.
Thoughts?
5 years, 8 months
WildFly tests with ByteBuddy enhancement are failing
by Gail Badner
Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1],
which are failing.
Here is Scott's PR with the updated tests: [2]
When I stepped into
org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
I can see that they are failing in ByteBuddy code.
I see that:
- enhancement of
org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets
skipped several times in a row;
- enhancement of some other classes get skipped;
- before trying to enhance
org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an
exception is thrown.
Unfortunately, I'm having trouble getting a good stacktrace to show what
happens in ByteBuddy code.
Here is what I'm seeing:
net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
/* class name differs from run to run */
calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( "
org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate(
classLoader, "org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5"
)
calls
classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"),
which returns null;
(I don't actually see a class file with this name)
returns new TypePool.Resolution.Illegal(
"org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"
)
returns TypePool.Resolution.Illegal
Ultimately, TypePool.Resolution.Illegal#resolve( ) throws
IllegalStateException, because the type description cannot be resolved.
I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy.
To build WildFly:
./build.sh clean install -DskipTests=true
To run the test:
cd testsuite/integration/basic
mvn install
-Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase
Help would be very much appreciated.
Thanks,
Gail
[1] https://issues.jboss.org/browse/WFLY-11891
[2] https://github.com/wildfly/wildfly/pull/12180
5 years, 8 months
Hibernate Search 6.0.0.Alpha3 released
by Yoann Rodiere
Hello,
We just published Hibernate Search 6.0.0.Alpha3, the third release for the
still-in-development 6.0 branch. This release mainly adds support for more
field types and predicates, and brings more consistent and less verbose
APIs.
This version is an early technology preview, so be sure to read about it on
our blog before you try it out:
http://in.relation.to/2019/03/22/hibernate-search-6-0-0-Alpha3/
Cheers,
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
5 years, 8 months
Release Announcement: General Availability of Java 12 / JDK 12
by Rory O'Donnell
Hi Sanne,
*1) Release Announcement: General Availability of Java 12 / JDK 12 [1] *
* JDK 12, the reference implementation of Java 12, is now Generally
Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
https://jdk.java.net/12
This release includes the following eight features:
* JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)
* JEP 230: Microbenchmark Suite
* JEP 334: JVM Constants API
* JEP 340: One AArch64 Port, Not Two
* JEP 341: Default CDS Archives
* JEP 344: Abortable Mixed Collections for G1
* JEP 346: Promptly Return Unused Committed Memory from G1
* JEP 325: Switch Expressions (Preview)
<https://openjdk.java.net/jeps/325>
Thanks to everyone who contributed JDK 12, whether by creating features
or enhancements, logging bugs, or downloading and testing the
early-access builds.
*2) JDK 13 EA build 12, under both the GPL and Oracle EA licenses, is
now available at **http://jdk.java.net/13**.*
* Proposed - Schedule for JDK 13 [2]
o 2019/06/13 Rampdown Phase One
o 2019/07/18 Rampdown Phase Two
o 2019/08/08 Initial Release Candidate
o 2019/08/22 Final Release Candidate
o 2019/09/17 General Availability
* Recent Bug fixes of Interest
o Build 9:
+ 8214719: Deprecate -Xverify:none option
+ 8216360: Deprecate -XX:CompilationPolicyChoice
o Build 10:
+ 8218995: Deprecate the -XX:FailOverToOldVerifier option
o Build 12 : 8160247: Mark deprecated javax.security.cert APIs
with forRemoval=true
+ 8220050: Deprecate -XX:-ThreadLocalHandshakes
+ Apache Lucene Reported - 8219448: split-if update_uses
accesses stale idom data
* Changes in this build [3]
Rgds,Rory
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002718.html
[2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-March/002716.html
[3] Changes
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B11%22%3A...>
in this build
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
5 years, 8 months
