Thanks Goktug for clarifying - I am personally in favor of a more coarse
approach, more future proofed approach that will end up with making changes
now rather than later. And to your followup, agreed, all else equal, let's
avoid supersource.
Thomas - While I made a Java8-first option was the
(which you already pointed but what matters me the most :))
On Tue, Jun 30, 2020 at 11:39 AM Goktug Gokdogan wrote:
> Super sourcing with tests is errorprone; it is easy to get one method
> added in one version but note the other and basically you end up testing
> nothing.
>
> On Tue, Jun 30,
Super sourcing with tests is errorprone; it is easy to get one method added
in one version but note the other and basically you end up testing nothing.
On Tue, Jun 30, 2020 at 1:36 AM Thomas Broyer wrote:
> So, IIUC, there are 2 distinct issues, but both related to JDK versions.
>
> First, the
Thanks very much.
I was using it because it allows me to modify the uploaded file name from
the client's side. Is it possible to do that using FileUpload?
On Tuesday, June 30, 2020 at 5:27:47 PM UTC+3, Colin Alworth wrote:
>
> It looks like this isn't part of GWT itself, but an external
It looks like this isn't part of GWT itself, but an external library.
Here's a stackoverflow post i found from a few years ago that seems to
address your issue:
https://stackoverflow.com/questions/31424639/gwt-error-when-uploading-file-with-singleuploader
It looks like the project might live
When I upload a file using SingleUploader or MultiUploader, the file gets
uploaded but the uploader's progress bar gets stuck at 0% for a very, very
long time.
When I try to upload a second file in the same session, I get this message:
> There is already an active upload, try later.
>
>
Thank you very much for quick responses.
Here are Vulnerabilities listed -
Gwt-dev.jar -
1.1 Vulnerable version of jetty library(current version-- 9.2.14, available
version -9.2.27+ )
[Associated CVEs -
CVE-2017-7656,CVE-2017-7657,CVE-2017-7658,CVE-2017-9735,CVE-2018-12536]
1.2 Vulnerable
So, IIUC, there are 2 distinct issues, but both related to JDK versions.
First, the doclet/taglet where JDK8 has com.sun.javadoc and JDK9+ have
jdk.javadoc.doclet. This is an internal tool, so it would be wasted effort
to maintain 2 versions. Either we keep the current code and require JDK8,