UnicodeDecoder U+FFFE handling

[Clément MATHIEU]

Hi,

I am wondering if UnicodeDecoder handling of U+FFFE is compliant with
current Unicode specification. Supsicious code is:

   if (c == REVERSED_MARK) {
// A reversed BOM cannot occur within middle of stream
return CoderResult.malformedForLength(2);
   }

Up to Unicode 6.3 Unicode specification said that U+FFFE is a non
character and that non characters "should never been interchanged".
Returning CR_MALFORMED on U+FFFE appears to be correct for Java 8
(Unicode 6.2).

However, Unicode 7 changed that and now says: 

  Applications are free to use any of these noncharacter code
  points internally. They have no standard interpretation when
  exchanged outside the context of internal use. However, they are
  not illegal in interchange, nor does their presence cause Unicode
  text to be ill-formed. [...] They are not prohibited from
  occurring  in  valid  Unicode  strings  which  happen  to  be  in
  terchanged. [...]. If a noncharacter is received in open
  interchange, an application is not required to interpret it in
  any way. It is good practice, however, to recognize it as a
  noncharacter and to take appropriate action, such as replacing it
  with U+FFFD replacement character, to indicate
  the  problem  in  the  text.  It  is  not  recommended  to  simpl
  y  delete  noncharacter  code points from such text, because of
  the potential security issues caused by deleting uninterpreted
  characters.

See:
 - http://www.unicode.org/versions/corrigendum9.html
 - https://www.unicode.org/versions/Unicode11.0.0/ch23.pdf (23.7)

Do you think that returning CR_MALFORMED is still OK?

Regards,
Clément MATHIEU

Re: jpackage EA Build 0

[Andy Herrick]

When there is a --files arg this works as expected, all jars are added 
to the classpath in the config file.


When there is no --files arg, only the jar files at the top level of the 
input dir are added to the classpath in the config file.


I filed  bug JDK-8215900 
 and will be fixing soon.



/Andy

On 12/19/2018 4:57 PM, Scott Palmer wrote:

If the main jar is in a subfolder the .cfg file is written incorrectly leading 
to:
   
   Error: Could not find or load main class 

   Caused by: java.lang.ClassNotFoundException: 

Which I only found by manually running:

./MyApp.app/Contents/MacOS/MyApp

as double clicking doesn’t seem to show that output anywhere (I tried to find 
it in the Console.app output, but didn’t).

In my case the main jar is in a ‘libs’ subfolder.  The image is built 
correctly, with the subfolder under the ‘Java’ folder in the Mac application 
bundle.  However, the cfg file had:

   app.mainjar=MyMainJar-1.0.0.jar

instead of:

app.mainjar=libs/MyMainJar-1.0.0.jar


When I manually made that edit, it started to work.


Scott



On Dec 14, 2018, at 7:46 AM, Andy Herrick  wrote:

I am pleased to announce that the first EA build of jpackage is now available 
at : https://jdk.java.net/jpackage/

This is an early access build of JEP 343: Packaging Tool 
, aimed at testing a prototype 
implementation of jpackage,

This build is intended for developers interested in jpackage, and is provided as a convenience 
so that they don't need to build from the source code 
 (branch="JDK-8200758-branch").

Warning: This build is based on an incomplete version of JDK 12 
.

Please send feedback via e-mail to core-libs-dev@openjdk.java.net

/Andy

Re: enhanced for loop with multiple iteration variables

[forax]

- Mail original -
> De: "Alan Snyder" 
> À: "Remi Forax" 
> Cc: "core-libs-dev" 
> Envoyé: Vendredi 21 Décembre 2018 03:20:46
> Objet: Re: enhanced for loop with multiple iteration variables

> Lambdas are clean, but limited in current Java compared to nested blocks.
> 
> Are full featured lambdas on the horizon?

not in the immediate future, co-routine, sealed class, record, pattern 
matching, value type and reified generics are the next features.

> 
> If not, then we still need loops and iterators.
> 
>  Alan

Rémi

> 
> 
> 
> 
>> On Dec 20, 2018, at 3:00 PM, Remi Forax  wrote:
>> 
>> or
>>  map.forEach((key, value) -> {
>>...
>>  });
>> 
>> Rémi
>> 
>> - Mail original -
>>> De: "Brian Goetz" 
>>> À: "Alan Snyder" , "core-libs-dev"
>>> 
>>> Envoyé: Jeudi 20 Décembre 2018 23:50:15
>>> Objet: Re: enhanced for loop with multiple iteration variables
>> 
>>> For Map, you can do:
>>> 
>>> for (Map.Entry e : map.entrySet()) { ... }
>>> 
>>> and you're already there.
>>> 
>>> 
>>> 
>>> On 12/19/2018 9:54 AM, Alan Snyder wrote:
 Has any consideration been given to supporting iterators that provide more 
 than
 one iteration variable in the enhanced for loop?
 
 Obvious uses would be maps (keys and values) and lists (indexes and 
 values).
 
 I have in mind keeping the syntactic sugar approach by using one or more
 extensions of the Iterator/Iterable interfaces, such as, for example:
 
 interface Iterator2 extends Iterator {
   E2 get2();
 }
 
 with the extra methods providing the values for the extra variables 
 (associated
 with the previous call to next).
 
 Extending interfaces is not required, but it makes the trailing variables
 optional, which might be useful. For example, the same iterator could 
 provide
 values or values and keys.
 
 The fact that this approach only works for a fixed set of numbers of 
 variables
 does not bother me unduly.
 
   Alan