[JBoss JIRA] (ERT-647) Resolve remaining issues with Batik 1.9.1
by Roland Grunberg (Jira)
[ https://issues.jboss.org/browse/ERT-647?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg commented on ERT-647:
-------------------------------------
I have received confirmation that my proposed fixes would make Batik 1.9.1 usable by BIRT from committers on the project.
Need to hear back with respect to whether lack of full 1.10 stack is a no-go for them, or whether they'd be willing to accept 1.9.1.
> Resolve remaining issues with Batik 1.9.1
> -----------------------------------------
>
> Key: ERT-647
> URL: https://issues.jboss.org/browse/ERT-647
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
> Priority: Major
>
> Batik 1.9.1 had some remaining issues that prevented the full stack from being adopted during the Photon release train by some other projects (eg. Sirius, Papyrus, GMF, BIRT, Graphiti, etc.)
> We should resolve the remaining issues, re-include all the bundles in the stack and finally upgrade to Batik 1.10.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ERT-666) Improve JDT Indexer performance for method reference lookups
by Roland Grunberg (Jira)
[ https://issues.jboss.org/browse/ERT-666?page=com.atlassian.jira.plugin.sy... ]
Roland Grunberg updated ERT-666:
--------------------------------
Description:
Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
The methodRef category table currently stores :
(symbol, number of arguments) -> document numbers (classfiles)
toString/0 -> [1, 4, 5, 25]
The proposal would change this to :
(symbol, symbol's classname, classname) -> document numbers (classfiles)
toString/0/java.lang.Object -> [1, 4, 5, 25]
Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
(/) Make the patch mostly correct
(/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
(?) Detect method references even in dead code (this is supported by existing indexer)
(/) More complicated performance test against top 500 used JRE references
(/) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
Upstream Bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=539159
was:
Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
The methodRef category table currently stores :
(symbol, number of arguments) -> document numbers (classfiles)
toString/0 -> [1, 4, 5, 25]
The proposal would change this to :
(symbol, symbol's classname, classname) -> document numbers (classfiles)
toString/0/java.lang.Object -> [1, 4, 5, 25]
Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
(/) Make the patch mostly correct
(/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
(?) Detect method references even in dead code (this is supported by existing indexer)
(?) More complicated performance test against the Eclipse Platform itself for java.lang.Object.toString()
(?) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
Upstream Bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=539159
> Improve JDT Indexer performance for method reference lookups
> ------------------------------------------------------------
>
> Key: ERT-666
> URL: https://issues.jboss.org/browse/ERT-666
> Project: Eclipse Release Train
> Issue Type: Task
> Reporter: Roland Grunberg
> Assignee: Roland Grunberg
> Priority: Major
>
> Based on discussions with Igor, various proposals were made to improve the method reference lookup times of the JDT Indexer.
> One particular suggestion, which should be possible, with least amount of friction, would be to provide more information about the declaring type of a method in the indexer format.
> The methodRef category table currently stores :
> (symbol, number of arguments) -> document numbers (classfiles)
> toString/0 -> [1, 4, 5, 25]
> The proposal would change this to :
> (symbol, symbol's classname, classname) -> document numbers (classfiles)
> toString/0/java.lang.Object -> [1, 4, 5, 25]
> Doing so should reduce the number of post-processing changes needed to verify that the declaring type of the first set of matches corresponds to the declaring type of the selected reference.
> (/) Make the patch mostly correct
> (/) Basic performance test with just a JVM target platform, and lookup of java.lang.Object.toString()
> (?) Detect method references even in dead code (this is supported by existing indexer)
> (/) More complicated performance test against top 500 used JRE references
> (/) A more thorough correctness test to identify any additional differences. (eg. test every single possible method reference, not just toString() )
> Upstream Bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=539159
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JBIDE-26441) The server was shutdown forcefully. All processes were terminated.
by Rakesh Jain (Jira)
Rakesh Jain created JBIDE-26441:
-----------------------------------
Summary: The server was shutdown forcefully. All processes were terminated.
Key: JBIDE-26441
URL: https://issues.jboss.org/browse/JBIDE-26441
Project: Tools (JBoss Tools)
Issue Type: Bug
Environment: eclipse.buildId=11.3.0.GA-v20180413-0714-B2352
java.version=1.8.0_181
jboss data virtualization server 6.3
Reporter: Rakesh Jain
eclipse.buildId=11.3.0.GA-v20180413-0714-B2352
java.version=1.8.0_181
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments: -product com.jboss.devstudio.core.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -product com.jboss.devstudio.core.product
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (JBIDE-26435) Hibernate JPA Model Generator and Java 11
by Jeff MAURY (Jira)
[ https://issues.jboss.org/browse/JBIDE-26435?page=com.atlassian.jira.plugi... ]
Jeff MAURY closed JBIDE-26435.
------------------------------
Resolution: Cannot Reproduce
> Hibernate JPA Model Generator and Java 11
> -----------------------------------------
>
> Key: JBIDE-26435
> URL: https://issues.jboss.org/browse/JBIDE-26435
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: maven
> Affects Versions: 4.9.0.Final
> Reporter: Cody Lerum
> Priority: Major
> Attachments: screenshot-1.png
>
>
> Not sure if this ends up being related to Jboss tools or just the Eclipse JDT
> But on 2018-09 with 4.9.Final a project cannot be cleanly built using the org.hibernate:hibernate-jpamodelgen
> Everything builds and then at the end it seems to delete the generated sources.
> This only occurs it the Java 11 support plugin is installed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months