Skip to main content

New technologies

31 replies [Last post]
denismo
Offline
Joined: 2003-06-28

Do you think that J2SE in Mustang should include some previously missing technology or library? Post your suggestions here.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02

> IMHO, if you can do it in C, you should be able to do
> it in Java. A Java program running as root can

That would mean adding pointers, direct memory access, etc. etc....

vpatryshev
Offline
Joined: 2004-06-30

Interesting; every time someone wants to write a program in Java, and needs an API that is freely available to any c, perl, php, python, c# or even basic programmer, there is a choir warning about security issues. As if java programmers are by default either dumber or malitiouser than c programmers. I think, the contrary is closer to the truth.

jkeatley
Offline
Joined: 2004-05-04

IMHO, if you can do it in C, you should be able to do it in Java. A Java program running as root can change files under /etc. A C program running as root can change files under /etc and also create and manipulate raw sockets. I think it is an artificial distinction to say that some things must never be done in Java, just because it is Java. If a user doesn't have rights to do a particular thing, they can't do it, no matter what language they are running. If raw sockets are so unsafe, let's remove the system calls from UNIX (and Windows, for that matter), so no one can write a C program that can access them either.

I have had all three of my votes pointed to this RFE for quite some time. Please join me in voting for this. I don't want other languages able to do things we can't do in Java.

> In general, for raw sockets to work, the process has
> to run as root. That means the entire JVM is running
> as root.
>
> There are two problems with this: first, not
> everyone
> can run as root. You can install a set-uid-root
> executable,
> so that program runs as root, but then you'd have to
> install
> a set-uid-root version of the java interpreter.
> That's a pretty dangerous thing to have lying around
> d a system.
>
> Secondly, you have a gigantic closed-soruce program
> running as root. Most security minded people are
> much
> happier with a small compilable C program that they
> y can
> inspect.
>
> The point is that just adding SOCK_RAW as a socket
> option doesn't really solve the problem.
>
> But you are right that raw sockets are used for far
> more than just ping.
>
> If you are really doing cutting-edge network
> research
> you can write a set-uid-root shim to get the raw
> socket
> access. Yes, it will be platform dependant, but
> there are really only 2 platforms to deal
> with -- Unix and Windows.
>
> -- cary

cobrien
Offline
Joined: 2004-06-09

> IMHO, if you can do it in C, you should be able to do
> it in Java. A Java program running as root can
> change files under /etc. A C program running as root
> can change files under /etc and also create and
> manipulate raw sockets.

Yes, but with a simple C program you can inspect
the source. The source for the JVM and all associated
libraries is not available to all of us, and even
if it were I would not like to be responsible for a
security audit of that code.

The real problem is the underlying all-or-nothing Unix
permission model. Some newer unix implementations provide
finer-grained security models, which would make a ,
safe Java implementation of SOCK_RAW possible. Of course
you would need Java access to this, or a set-uid-root
java launcher that granted the capability, dropped
root, and execd the JVM. I guess it depends on how
the capabilities are implemented.

A better solution would be to have network sockets
protected by the file system. Does plan 9 do this?

Enough... Back to work...

-- cary

cobrien
Offline
Joined: 2004-06-09

In general, for raw sockets to work, the process has to run as root. That means the entire JVM is running as root.

There are two problems with this: first, not everyone
can run as root. You can install a set-uid-root executable,
so that program runs as root, but then you'd have to install
a set-uid-root version of the java interpreter. That's a pretty dangerous thing to have lying around a system.

Secondly, you have a gigantic closed-soruce program running as root. Most security minded people are much
happier with a small compilable C program that they can
inspect.

The point is that just adding SOCK_RAW as a socket
option doesn't really solve the problem.

But you are right that raw sockets are used for far more than just ping.

If you are really doing cutting-edge network research
you can write a set-uid-root shim to get the raw socket
access. Yes, it will be platform dependant, but
there are really only 2 platforms to deal
with -- Unix and Windows.

-- cary

zander
Offline
Joined: 2003-06-13

> In general, for raw sockets to work, the process has
> to run as root. That means the entire JVM is running
> as root.

correct; but specifying a security policy (or just a security manager from the command line) allows you to limit the functionality of the application in ways that are impossible for any c application.
In other words; running as root, but still have the networking code running in a sandbox is a security dream; not a nightmare.

> Secondly, you have a gigantic closed-soruce program
> running as root. Most security minded people are much
> happier with a small compilable C program that they can
> inspect.
Thats a good point; perhaps this request should not be honored in the Sun JVM; the security minded people should just ask the open source JVM people to implement this outside of the Java spec.

thulin
Offline
Joined: 2005-03-24

It would be nice to have
[b]javax.spell[/b]

Spell checking. RI could use ThunderBird language modules.

dreamtangerine
Offline
Joined: 2004-03-04

Hi guy.

If you want a free spell checker that use OpenOffice dictionaries try (is a port of MySpell to java) :

http://jmyspell.javahispano.net/

is in spanish, but the functions are in (poor) english, you can download from the CVS http://javahispano.net/scm/?group_id=68

if you want help to translate, you are welcome.

Have a nice day and enjoy.
DreamTangerine.

harikrushna
Offline
Joined: 2005-02-25

sir
i want to trasmit some data using connection oriented socket in java
i want to use ip_tos field of ip header
i am able to set the value of precedence field for datagram sockets
using settrafficclass of java
but if i use same thing for tcp sockets it is disabling
i want to give priority to my connection oriented socket using precedence field
i want iptos_,lowdelay for my connection oriented socket
if it is possible
pls send me the code

harikrushna
Offline
Joined: 2005-02-25

sir
i want to trasmit some data using connection oriented socket in java
i want to use ip_tos field of ip header
i am able to set the value of precedence field for datagram sockets
using settrafficclass of java
but if i use same thing for tcp sockets it is disabling
i want to give priority to my connection oriented socket using precedence field
i want iptos_,lowdelay for my connection oriented socket
if it is possible
pls send me the code

harikrushna
Offline
Joined: 2005-02-25

sir
i want to trasmit some data using connection oriented socket in java
i want to use ip_tos field of ip header
i am able to set the value of precedence field for datagram sockets
using settrafficclass of java
but if i use same thing for tcp sockets it is disabling
i want to give priority to my connection oriented socket using precedence field
i want iptos_,lowdelay for my connection oriented socket
if it is possible
pls send me the code

vhi
Offline
Joined: 2004-10-11

This is not the forum for such questions. Repeating your questions here will not help.

xiangya
Offline
Joined: 2003-09-24

Hi,
I wonder why sun don't accept javolution's advice?

jwenting
Offline
Joined: 2003-12-02

I wonder why Sun doesn't allow compilation of C++ code into Java bytecode using the Java compiler.
And C code, Pascal, Fortran, Cobol, and every other language out there...

We do not need an even larger and more bloated language, we need a language that's smaller and leaner, a language with a lot of the crud picked up over the years removed (some of it to optional packages, a lot of it gone for good.

markf
Offline
Joined: 2005-01-20

I think Java needs a curses library, so that we can do serious console work. All the third-party curses libraries are either really crummy, or are completely dead projects.

smartinumcp
Offline
Joined: 2004-09-07

Interesting idea. Definitely a frustration that you can only do swing or command line for now. I did curses a while back in school and found it a fun (maybe they didn't) lesson for the undergrads to work on. If it would work cross-platform I'm all for it.

regexguy
Offline
Joined: 2003-06-20

I have previously suggested that WebStart should be extended to handle signed jars based on version only, not version + server it came from.

I'm wondering if a JarStart might be useful -- sort of have the webstart mechanism available to an individual library (not just applications) to facilitate keeping it up to date. There could be a little javaws like interface to manage your downloaded jars.

rp0428
Offline
Joined: 2004-12-21

Currently there is no way to verify that a given set of .CLASS files was compiled with the same compiler or even a compiler by the same manufacturer.

Once a class file is produced one can't be certain it was compiled with a corporate approved compiler version. Many obscure bugs have been introduced because a class file was created by a developer with a compiler that was different than the one used for other classes in the application.

The next time the CLASS file format needs to be modified I would like to see the addition of information that indicates what compiler and version was used to compile the class file.

Currently there are U2 fields for major version and minor version:
u2 minor_version;
u2 major_version;

I would add:
u2 javac_manufacturer;
u2 javac_version;

Although this would not guard against hacker changes to 'spoof' the javac information it would allow corporate Q/A and migration teams to identify class files that were not produced with the same compiler.

Granted this would add 4 bytes to each class file but I think the overhead is worth it.

peterahe
Offline
Joined: 2004-11-22

In a day or two, you can cast your votes here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6214503

rp0428
Offline
Joined: 2004-12-21

I suggest that some kind of conditional compilation facility be added to Java.

Current developer's and third party companies are developing workarounds that use FINAL STATIC variables to control the inclusion of logging or debugging code or to include/exclude assertions.

The only reason an artificial means is currently needed is because there is no way to identify conditional 'blocks' of code in Java.

This might be done by modifying the '{' opening block tag to '{debug1' or '{log'. The compiler would then include or exclude the block based on a system or command-line property.

A simple change like this would eliminate the need to include 'if DEBUG.DEBUGGING' 'if' blocks. These blocks corrupt the language.

Another way to accomplish the same thing is to introduce the concept of 'layers' to Java source files.

Currently a Java class file is homogenous: that is, documentation, application code, debugging statements and logging statements are all intermixed in one file. Except for documentation that uses Javadoc tags the elements cannot be easily or automatically separated.

What is both interesting and curious is that each of these elements is generally independent of each other. That is each element could be hidden (or even removed without affecting either the physical or logical meaning of the other elements.

This strongly suggests the use of a ‘layer’ paradigm to represent the elements. This would be analogous to the layer concept used in CAD packages for architecture. A CAD drawing for a home might have a plot layer, landscape layer, framing layer, electrical layer, plumbing layer, etc. One can easily hide or display any layer.

The Java compilation process could then easily exclude any of the layers (e.g. the debugging layer) as desired. This could be done at the CLASS level rather than globally.

If one, or only a few classes need to be debugged or logged the modified block tag "{logid=3783" or layer tag would cause the compiler to include the log code for this block in the class rather than globally.

Suppose that each element is contained within a separate layer. Thus there is a documentation layer, an application code layer, a log layer and a debug layer. There could also be other layers (security, timing metrics, etc).

A GUI Java editor could hide or display any or all of the layers. Development would start with the document layer. The class file, variable section, and methods would be documented. Pseudo-code could be added to the methods to define the logic flow.

The application layer would then be written. Because of the use of layers the code would appear to be intermixed with the documentation but would actually be maintained on its own layer. There could, of course, be synchronization between the layers.

A different developer at a later point could add debugging code. Because debugging code is on it’s own layer it can be written without impacting (or introducing bugs in) the application code.

Logging code could also be added that is independent of the application and debugging code.

During compilation you would indicate to the compiler what layers to include in the class file. If you don’t want debugging code then don’t include the debug layer.

It may be possible to extend the 'layer' concept to the classloading stage so that even if a 'log' or 'debug' layer is present in the class file the classloader will not load it.

The 'layer' paradigm would also make it easier for a company to add 'log' or 'debug' layers to third party class files without needing the source code to the file.

rp0428
Offline
Joined: 2004-12-21

This could be implemented in conjunction with http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4879835.

RFE 4879835 suggests adding JFluid-like dynamic bytecode instrumentation.

Implementing a 'layer' paradigm for Java would accomplish the requested functionality of dynamic bytecode instrumentation in a more java-compatible way.

The dynamic part would relate to enabling/disabling of various layers (app code layer, log layer, debug layer, etc). The code for the various layers would be produced the same way that Java source code is produced now and could be interweaved (overlaid) with previously compiled classes (without needing the source code) via introspection.

Essentially you could dynamically instrument existing class files by adding new layers. The classloader could then selectively load or not load any desired set of layers and even if layers are loaded they could be disabled at load time or dynamically disabled.

If the instrumentation layers were loaded and disabled the JVM hook to enable/disable layers would be a simple boolean function call. Having a simple boolean function minimizes the impact a debug hook has on a running JVM.

tim12s
Offline
Joined: 2004-02-02

Good Windows/COM+ integration. I'm not sure how far this should go, but I believe .NET will out manuever Java in the near future because of this. I dont know if its worthwhile, but I do know that i've been through hell to get some COM+ objects working properly and I wouldnt want others to go through the same pit of pain.

Not exclusively the domain of COM+, I think there should be certain desktop integration components. How do you create tray items, etc in a platform independant way, etc.

How could I make a java object integrate with outlook.

Hmm... one point in particular. I know its possible to expose a Java Bean as a COM component. It _must_ be possible to implement a COM interface as a java bean. There is no way to migrate piece meal older technologies to a better technology and COM+ integration is not sufficient at the moment. I unfortunately see this market being snatched by .NET.

The relevance is that while I see java behind corporate intranets, I see nothing for my grandma.

Java seems confined to business because of deployment issues and platform integration. I raise this issue based on ATI and NVidia both releasing the next version of their drivers as .NET runtimes. Why? <--- solve this and then java is 'complete'.

zander
Offline
Joined: 2003-06-13

> Good Windows/COM+ integration. I'm not sure how far
> this should go, but I believe .NET will out manuever
> Java in the near future because of this. I dont know
> if its worthwhile, but I do know that i've been
> through hell to get some COM+ objects working
> properly and I wouldnt want others to go through the
> same pit of pain.

Please inform us what exactly you are trying to do; obviously using the COM components is not really relevent; if only because .NET is replacing them with something else. So, please state a (technicle) example where Java is missing functionality.

kenhorn
Offline
Joined: 2003-06-11

Native integration issues are killing Java on the Desktop. There needs to be a much better solution than JNI -- many Java developers today (and more tomorrow) don't know how to write in C, never mind compile / link / port across Win/Linux etc. For those who have been there, we don't want to go back.

I think the Unsafe class or equiv could be expanded to give real native style access -- it doesn't need to be a security issue either, just make it the equivalent of JNI from a security point of view.

By changing a single registry entry, I can take any C# class and then simply invoke the methods from inside Excel. Why can't I do this in Java? I realise there are threading / reference issues with some calls but these are all solvable. If the basic ability to make any native invocation is there, frameworks that deal with the differences in threading models etc can be built (outside the JDK imho, open source most likely, maybe on java.net). The latter will need to evolve, but there should be a way to invoke any library function.

I want to take any DLL/lib and call into / regsiter callbacks from Java. No C code involved. The JDK might provide a command to generate a Java typelib.jar or something that does the low level mapping but no C code please.

If Java was painless as a web services client stack on the desktop for Excel to call, most projects I've seen in the last 2 years (finance industry) would drop .NET development for pure simplicity reasons.

I want integration as good as Eclipse gives, if not better -- eg most trading apps would love to embedd an excel sheet in a swing gui but don't for fear of the complexity / pain involved. (Excel has other issues but let's not go there).

There's been a Java-COM bridge for ages - not really supported as far as I know though. Why not?

zander
Offline
Joined: 2003-06-13

In short; PLEASE don't put any extra libraries in the JRE. The track-record Sun has shown us is that external, more-often-released libraries always provide better alternatives then the ones the JRE has shipped.

Its simple really; the amount of open source developers for libraries as JDom, Dom4J, Log4J are EACH more then the amount of developers sun is willing to work on these components combined. The result is that each of these solutions is better developed and more stable then the JRE versions ever will be. Libraries in the JRE are a maintainance hazard and bring you nothing but headaces due to more bugs being posted.

I would really be dissapointed if more libraries were integrated in the JRE at all.

grlea
Offline
Joined: 2004-05-26

Having libraries moved into the JRE also has the disadvantage that the release cycle for that library is slowed RIGHT down. Because it's in J2SE, it means the API can really only change once every 1 + 1/2 years (J2SE major release cycle target timeframe), which for many technologies, especially young ones, is just too long.

If an API could be better, it should be able to get better and be released ASAP, not in a year and a half's time when everything else unrelated to it is also ready.

Standard extensions are the way to go, in my opinion, but it'd really be great to have some way of these extensions being automatically updated or available, ala. WebStart's j2se functionality. i.e. developers need to be able to specify they need version X (or X+) of a standard extension. If it's already installed, it's used, if not, it's downloaded automatically from Sun.

While the JRE is a great idea, at 14Mb I think it's a barrier to entry for the majority of people who aren't Java programmers! A dial-up user will NEVER run a WebStart app if it comes up and says "Can I just download this 14Mb JRE before you run this app?" It needs to be chopped up and distributed on an as-needed basis.

bjb
Offline
Joined: 2003-06-12

This is realy a missing technology.

http://java.sun.com/j2se/1.5.0/docs/guide/net/socketOpt.html
And no, like stated in the standard javadoc :
"RAW/ICMP SOCKETS:
The main argument in favor of this one seemed to be so people could write "ping" in java. Security nightmare. Must be root on UNIX machines."

This is wrong :

#1 - It is not a security nightmare :

Permission for using RAW socket will be not granted by default by the VM policy. You have to update the policy file to get it.

Once updated, you will still rely on the OS policy to get this working. For instance on XP, you have to be Administrator to get access to the RAW socket API, AFAIK.

So, this is not anykind of a nightmare.

#2 - No we don't need this only to bring "ping"

This prevent people from developing most of the network components that handle the network (routers, bridges, NAT ... ) for instance.

And there is no solution to do that other than to involve in some non portable JNI that will be heavilly platform dependant.

#3 The new "ping" API does not solve the problem

#4 RFE is open since 2002 !

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4727550

My understanding is that this should be done in the SPI way as well to enable multiple&plugable RAW IP implentation ...

So, if you want Java to be still on the network edge, you got to implement this for mustang.

zander
Offline
Joined: 2003-06-13

> So, if you want Java to be still on the network edge,
> you got to implement this for mustang.

Don't you think not being able to get the netmask of a device kind of makes being on the network edge impossible to begin with?

bjb
Offline
Joined: 2003-06-12

I did not saw the javadoc say "netmask are a security nightmare" ;)

Ok, to go back on the topic ... Definitivelly we need RAW socket IP ASAP :)

mdbuck
Offline
Joined: 2004-10-08

I like the way the XML pull parser works in C#. A similar way to parse XML in Java would be very helpful.

forax
Offline
Joined: 2004-10-07

yes, the xml pull parser API could be integrated
to JAXP

see http://www.xmlpull.org/